Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Gestion des utilisateurs pour les points de terminaison du serveur
Dans les sections suivantes, vous trouverez des informations sur la façon d'ajouter des utilisateurs à l'aide d' AWS Transfer Family un fournisseur d'identité personnalisé AWS Directory Service for Microsoft Active Directory ou d'un fournisseur d'identité.
Vous pouvez également stocker la clé publique SSH (Secure Shell) dans les propriétés de chaque utilisateur. Cela est nécessaire pour l'authentification par clé. La clé privée est stockée localement sur l'ordinateur de votre utilisateur. Lorsque votre utilisateur envoie une demande d'authentification à votre serveur via un client, celui-ci confirme d'abord que l'utilisateur a accès à la clé privée SSH associée. Le serveur authentifie ensuite correctement l'utilisateur.
**Note**
Pour le déploiement et la gestion automatisés des utilisateurs utilisant plusieurs clés SSH, consultez[Modules Transfer Family Terraform](terraform.md).
En outre, vous spécifiez le répertoire personnel, ou répertoire de destination, d'un utilisateur et vous lui attribuez un rôle Gestion des identités et des accès AWS (IAM). Vous pouvez éventuellement fournir une politique de session pour limiter l'accès des utilisateurs uniquement au répertoire de base de votre compartiment Amazon S3.
**Important**
AWS Transfer Family empêche les noms d'utilisateur de 1 ou 2 caractères de s'authentifier auprès des serveurs SFTP. De plus, nous bloquons également le nom `root` d'utilisateur.
Cela s'explique par le grand nombre de tentatives de connexion malveillantes effectuées par des scanners de mots de passe.
## Comparaison entre Amazon EFS et Amazon S3
Caractéristiques de chaque option de stockage :
+ Pour limiter l'accès : Amazon S3 prend en charge les politiques de session ; Amazon EFS prend en charge les utilisateurs, les groupes et les groupes secondaires POSIX IDs
+ Les deux public/private touches de support
+ Les deux prennent en charge les répertoires personnels
+ Les deux prennent en charge les répertoires logiques
**Note**
Pour Amazon S3, l'essentiel de la prise en charge des annuaires logiques se fait via API/CLI. Vous pouvez utiliser la case à cocher **Restreint** de la console pour verrouiller l'accès d'un utilisateur à son répertoire personnel, mais vous ne pouvez pas spécifier de structure de répertoire virtuel.
## Répertoires logiques
Si vous spécifiez des valeurs de répertoire logiques pour votre utilisateur, le paramètre que vous utilisez dépend du type d'utilisateur.
+ Pour les utilisateurs gérés par des services, fournissez des valeurs de répertoire logiques dans. `HomeDirectoryMappings`
+ Pour les utilisateurs de fournisseurs d'identité personnalisés, fournissez des valeurs de répertoire logiques dans`HomeDirectoryDetails`.
AWS Transfer Family prend en charge la spécification d'une HomeDirectory valeur lors de l'utilisation du LOGICAL HomeDirectoryType. Cela s'applique aux utilisateurs gérés par le service, à l'accès à Active Directory et aux implémentations de fournisseurs d'identité personnalisés lorsque HomeDirectoryDetails ceux-ci sont fournis dans la réponse.
**Important**
Lorsque vous spécifiez a HomeDirectory avec LOGICAL HomeDirectoryType, la valeur doit correspondre à l'un de vos mappages de répertoires logiques. Le service valide cela lors de la création et des mises à jour des utilisateurs afin d'éviter que les configurations ne fonctionnent pas.
### Comportement par défaut
Par défaut, s'il n'est pas spécifié, HomeDirectory il est défini sur «/» pour le mode LOGIQUE. Ce comportement est inchangé et reste compatible avec les définitions utilisateur existantes.
+ Assurez-vous de faire correspondre votre entrée HomeDirectory à une *entrée* et non à une *cible*. Pour en savoir plus, consultez [Règles d'utilisation des répertoires logiques](logical-dir-mappings.md#logical-dir-rules).
+ Pour plus de détails sur la structure d'un répertoire virtuel, voir[Structure du répertoire virtuel](implement-log-dirs.md#virtual-dirs).
### Considérations relatives au fournisseur d'identité personnalisé
Lorsque vous utilisez un fournisseur d'identité personnalisé, vous pouvez désormais spécifier un HomeDirectory dans la réponse lorsque vous utilisez LOGICAL HomeDirectoryType. L'appel TestIdentityProvider d'API produira des résultats corrects lorsque l'IDP personnalisé spécifie un HomeDirectory en mode LOGIQUE.
Exemple de réponse IDP personnalisée avec HomeDirectory et 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\"}]"
}
```
## Quotas de groupe Active Directory
AWS Transfer Family a une limite par défaut de 100 groupes Active Directory par serveur. Si votre cas d'utilisation nécessite plus de 100 groupes, envisagez d'utiliser une solution de fournisseur d'identité personnalisée, comme décrit dans [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Cette limite s'applique aux serveurs utilisant les fournisseurs d'identité suivants :
+ AWS Service d'annuaire pour Microsoft Active Directory
+ AWS Service d'annuaire pour les services de domaine Entra ID
Si vous devez demander une augmentation de la limite de service, consultez [Service AWS les quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dans le *Références générales AWS*. Si votre cas d'utilisation nécessite plus de 100 groupes, envisagez d'utiliser une solution de fournisseur d'identité personnalisée, comme décrit dans [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Pour obtenir des informations de résolution des problèmes liés aux limites de groupe Active Directory, consultez[Limites de groupe Active Directory dépassées](auth-issues.md#managed-ad-group-limits).
**Topics**
+ [Comparaison entre Amazon EFS et Amazon S3](#efs-vs-s3-users)
+ [Répertoires logiques](#logical-dir-users)
+ [Quotas de groupe Active Directory](#ad-group-quotas)
+ [Travailler avec des utilisateurs gérés par des services](service-managed-users.md)
+ [Travailler avec des fournisseurs d'identité personnalisés](custom-idp-intro.md)
+ [Utilisation de AWS Directory Service pour Microsoft Active Directory](directory-services-users.md)
+ [Utilisation du AWS Directory Service pour les services de domaine Entra ID](azure-sftp.md)
# Travailler avec des utilisateurs gérés par des services
Vous pouvez ajouter des utilisateurs gérés par le service Amazon S3 ou Amazon EFS à votre serveur, en fonction du paramètre de **domaine** du serveur. Pour de plus amples informations, veuillez consulter [Configuration d'un point de terminaison de serveur SFTP, FTPS ou FTP](tf-server-endpoint.md).
Si vous utilisez un type d'identité géré par un service, vous ajoutez des utilisateurs à votre serveur compatible avec le protocole de transfert de fichiers. Dans ce cas, chaque nom d'utilisateur doit être unique sur votre serveur.
Pour ajouter un utilisateur géré par un service par programmation, consultez l'[exemple](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_Examples) de l'API. [CreateUser](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html)
**Note**
Pour les utilisateurs gérés par des services, il existe une limite de 2 000 entrées de répertoire logique. Pour plus d'informations sur l'utilisation de répertoires logiques, consultez[Utilisation de répertoires logiques pour simplifier vos structures de répertoires Transfer Family](logical-dir-mappings.md).
**Topics**
+ [Ajouter des utilisateurs gérés par le service Amazon S3](#add-s3-user)
+ [Ajouter des utilisateurs gérés par le service Amazon EFS](#add-efs-user)
+ [Gestion des utilisateurs gérés par des services](#managing-service-managed-users)
## Ajouter des utilisateurs gérés par le service Amazon S3
**Note**
Si vous souhaitez configurer un bucket Amazon S3 multi-comptes, suivez les étapes décrites dans cet article du centre de connaissances : [Comment configurer mon AWS Transfer Family serveur pour utiliser un bucket Amazon Simple Storage Service se trouvant dans un autre AWS compte ?](https://aws.amazon.com/premiumsupport/knowledge-center/sftp-cross-account-s3-bucket/) .
**Pour ajouter un utilisateur géré par le service Amazon S3 à votre serveur**
1. Ouvrez la AWS Transfer Family console sur [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), puis sélectionnez **Serveurs** dans le volet de navigation.
1. Sur la page **Serveurs**, cochez la case du serveur auquel vous souhaitez ajouter un utilisateur.
1. Sélectionnez **Ajouter un utilisateur**.
1. Dans la section **Configuration utilisateur**, pour **Nom d'utilisateur**, entrez le nom d'utilisateur. Ce nom d'utilisateur doit comporter au minimum 3 caractères et au maximum 100 caractères. Vous pouvez utiliser les caractères suivants dans le nom d'utilisateur : a—z, A-Z, 0—9, trait de soulignement « \$1 », tiret « - », point «. » et signe « @». Le nom d'utilisateur ne peut pas commencer par un tiret « - », un point «. » ou par le signe « @».
1. Pour **Access**, choisissez le rôle IAM que vous avez créé précédemment et qui donne accès à votre compartiment Amazon S3.
Vous avez créé ce rôle IAM à l'aide de la procédure décrite dans [Création d'un rôle et d'une politique IAM](requirements-roles.md). Ce rôle IAM inclut une politique IAM qui permet d'accéder à votre compartiment Amazon S3. Cela inclut également une relation de confiance avec le AWS Transfer Family service, définie dans une autre politique IAM. Si vous avez besoin d'un contrôle d'accès précis pour vos utilisateurs, consultez le billet de blog [Enhance data access control with AWS Transfer Family and Amazon S3](https://aws.amazon.com/blogs/storage/enhance-data-access-control-with-aws-transfer-family-and-amazon-s3-access-points/).
1. (Facultatif) Pour **Politique**, sélectionnez l'une des options suivantes :
+ **Aucun**
+ **Politique existante**
+ **Sélectionnez une politique dans IAM** : vous permet de choisir une stratégie de session existante. Choisissez **View** pour voir un objet JSON contenant les détails de la politique.
+ **Génération automatique d'une politique basée sur le dossier** de base : génère une politique de session pour vous. Choisissez **View** pour voir un objet JSON contenant les détails de la politique.
**Note**
Si vous choisissez **Générer automatiquement une politique basée sur le dossier** de base, ne sélectionnez pas **Restreint** pour cet utilisateur.
Pour en savoir plus sur les politiques de session[Création d'un rôle et d'une politique IAM](requirements-roles.md), consultez[Création d'une politique de session pour un compartiment Amazon S3](users-policies-session.md), ou[Approches dynamiques de gestion des autorisations](dynamic-permission-management.md).
1. Pour le **répertoire personnel**, choisissez le compartiment Amazon S3 dans lequel stocker les données à transférer AWS Transfer Family. Entrez le chemin d'accès au `home` répertoire dans lequel votre utilisateur atterrit lorsqu'il se connecte à l'aide de son client.
Si vous laissez ce paramètre vide, le `root` répertoire de votre compartiment Amazon S3 est utilisé. Dans ce cas, vérifiez que votre rôle IAM donne accès à ce répertoire `root`.
**Note**
Nous vous recommandons de choisir un chemin de répertoire contenant le nom d'utilisateur de l'utilisateur, afin d'utiliser efficacement une politique de session. La politique de session limite l'accès des utilisateurs dans le compartiment Amazon S3 au `home` répertoire de cet utilisateur.
1. (Facultatif) Pour **Restreint**, cochez la case afin que vos utilisateurs ne puissent accéder à rien en dehors de ce dossier et ne puissent pas voir le nom du compartiment ou du dossier Amazon S3.
**Note**
L'attribution d'un répertoire personnel à l'utilisateur et la restriction de l'utilisateur à ce répertoire personnel devraient suffire à verrouiller l'accès de l'utilisateur au dossier désigné. Si vous devez appliquer des contrôles supplémentaires, utilisez une politique de session.
Si vous sélectionnez **Restreint** pour cet utilisateur, vous ne pouvez pas sélectionner **Générer automatiquement une politique basée sur le dossier de** base, car le dossier de base n'est pas une valeur définie pour les utilisateurs restreints.
1. Pour la **clé publique SSH**, entrez la partie clé SSH publique de la paire de clés SSH.
Votre clé est validée par le service avant que vous puissiez ajouter votre nouvel utilisateur.
**Note**
Pour obtenir des instructions sur la façon de générer une paire de clés SSH, consultez [Génération de clés SSH pour les utilisateurs gérés par des services](sshkeygen.md).
1. (Facultatif) Pour **Clé** et **Valeur**, entrez une ou plusieurs balises sous forme de paires clé-valeur, puis choisissez **Ajouter** une balise.
1. Choisissez **Add (Ajouter)** pour ajouter votre nouvel utilisateur au serveur que vous avez choisi.
Le nouvel utilisateur apparaît dans la section **Utilisateurs** de la page de **détails du serveur**.
**Prochaines étapes** — Pour l'étape suivante, passez à[Transfert de fichiers via un point de terminaison serveur à l'aide d'un client](transfer-file.md).
## Ajouter des utilisateurs gérés par le service Amazon EFS
Amazon EFS utilise le modèle d'autorisation de fichier POSIX (Portable Operating System Interface) pour représenter la propriété des fichiers.
+ Pour plus d'informations sur la propriété des fichiers Amazon EFS, consultez la section [Propriété des fichiers Amazon EFS](configure-storage.md#efs-file-ownership).
+ Pour plus de détails sur la configuration de répertoires pour vos utilisateurs EFS, consultez[Configurer les utilisateurs Amazon EFS pour Transfer Family](configure-storage.md#configure-efs-users-permissions).
**Pour ajouter un utilisateur géré par le service Amazon EFS à votre serveur**
1. Ouvrez la AWS Transfer Family console sur [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), puis sélectionnez **Serveurs** dans le volet de navigation.
1. Sur la page **Servers**, sélectionnez le serveur Amazon EFS auquel vous souhaitez ajouter un utilisateur.
1. Choisissez **Ajouter un utilisateur** pour afficher la page **Ajouter un utilisateur**.
1. Dans la section **Configuration utilisateur**, utilisez les paramètres suivants.
1. Le **nom d'utilisateur** doit comporter un minimum de 3 et un maximum de 100 caractères. Vous pouvez utiliser les caractères suivants dans le nom d'utilisateur : a—z, A-Z, 0—9, trait de soulignement « \$1 », tiret « - », point ' . ', et au panneau « @ ». Le nom d'utilisateur ne peut pas commencer par un tiret « - », point ' . ', ou au panneau « @ ».
1. Pour **l'ID utilisateur** et l'**ID de groupe**, notez ce qui suit :
+ Pour le premier utilisateur que vous créez, nous vous recommandons de saisir une valeur égale à la fois **0** pour l'**ID de groupe** et **l'ID utilisateur**. Cela accorde à l'utilisateur des privilèges d'administrateur pour Amazon EFS.
+ Pour les utilisateurs supplémentaires, entrez l'ID utilisateur POSIX et l'ID de groupe de l'utilisateur. Ils IDs sont utilisés pour toutes les opérations Amazon Elastic File System effectuées par l'utilisateur.
+ Pour **l'ID utilisateur** et l'**ID de groupe**, n'utilisez pas de zéros en début de liste. Par exemple, **12345** c'est acceptable, ne l'**012345**est pas.
1. (Facultatif) Pour **Groupe secondaire IDs**, entrez un ou plusieurs groupes POSIX supplémentaires IDs pour chaque utilisateur, séparés par des virgules.
1. Pour **Access**, choisissez le rôle IAM qui :
+ Permet à l'utilisateur d'accéder uniquement aux ressources Amazon EFS (systèmes de fichiers) auxquelles vous souhaitez qu'il accède.
+ Définit les opérations de système de fichiers que l'utilisateur peut ou ne peut pas effectuer.
Nous vous recommandons d'utiliser le rôle IAM pour sélectionner le système de fichiers Amazon EFS avec accès au montage et read/write autorisations. Par exemple, la combinaison des deux politiques AWS gérées suivantes, bien que très permissive, accorde les autorisations nécessaires à votre utilisateur :
+ AmazonElasticFileSystemClientFullAccess
+ AWSTransferConsoleFullAccess
Pour plus d'informations, consultez le billet de blog sur la [AWS Transfer Family prise en charge d'Amazon Elastic File System](https://aws.amazon.com/blogs/aws/new-aws-transfer-family-support-for-amazon-elastic-file-system/).
1. Pour le **répertoire personnel**, procédez comme suit :
+ Choisissez le système de fichiers Amazon EFS que vous souhaitez utiliser pour stocker les données à transférer AWS Transfer Family.
+ Décidez si le répertoire de base doit être défini sur **Restreint**. Le fait de définir le répertoire de base sur **Restreint** a les effets suivants :
+ Les utilisateurs d'Amazon EFS ne peuvent accéder à aucun fichier ou répertoire en dehors de ce dossier.
+ Les utilisateurs d'Amazon EFS ne peuvent pas voir le nom du système de fichiers Amazon EFS (**fs-xxxxxxx**).
**Note**
Lorsque vous sélectionnez l'option **Restreint**, les liens symboliques ne sont pas résolus pour les utilisateurs d'Amazon EFS.
+ (Facultatif) Entrez le chemin du répertoire de base dans lequel vous souhaitez que les utilisateurs se trouvent lorsqu'ils se connectent à l'aide de leur client.
Si vous ne spécifiez pas de répertoire personnel, le répertoire racine de votre système de fichiers Amazon EFS est utilisé. Dans ce cas, assurez-vous que votre rôle IAM donne accès à ce répertoire racine.
1. Pour la **clé publique SSH**, entrez la partie clé SSH publique de la paire de clés SSH.
Votre clé est validée par le service avant que vous puissiez ajouter votre nouvel utilisateur.
**Note**
Pour obtenir des instructions sur la façon de générer une paire de clés SSH, consultez [Génération de clés SSH pour les utilisateurs gérés par des services](sshkeygen.md).
1. (Facultatif) Entrez des balises pour l'utilisateur. Pour **Clé** et **Valeur**, entrez une ou plusieurs balises sous forme de paires clé-valeur, puis choisissez **Ajouter** une balise.
1. Choisissez **Add (Ajouter)** pour ajouter votre nouvel utilisateur au serveur que vous avez choisi.
Le nouvel utilisateur apparaît dans la section **Utilisateurs** de la page de **détails du serveur**.
Problèmes que vous pouvez rencontrer lors de votre première connexion SFTP sur votre serveur Transfer Family :
+ Si vous exécutez la `sftp` commande et que l'invite ne s'affiche pas, le message suivant peut s'afficher :
`Couldn't canonicalize: Permission denied`
`Need cwd`
Dans ce cas, vous devez augmenter les autorisations liées à la politique pour le rôle de votre utilisateur. Vous pouvez ajouter une politique AWS gérée, telle que`AmazonElasticFileSystemClientFullAccess`.
+ Si vous entrez `pwd` à l'`sftp`invite pour consulter le répertoire personnel de l'utilisateur, le message suivant peut s'afficher, indiquant où se *USER-HOME-DIRECTORY* trouve le répertoire personnel de l'utilisateur SFTP :
`remote readdir("/USER-HOME-DIRECTORY"): No such file or directory`
Dans ce cas, vous devriez pouvoir accéder au répertoire parent (`cd ..`) et créer le répertoire personnel de l'utilisateur (`mkdir username`).
**Prochaines étapes** — Pour l'étape suivante, passez à[Transfert de fichiers via un point de terminaison serveur à l'aide d'un client](transfer-file.md).
## Gestion des utilisateurs gérés par des services
Dans cette section, vous trouverez des informations sur la façon d'afficher une liste d'utilisateurs, de modifier les détails des utilisateurs et d'ajouter une clé publique SSH.
+ [Afficher la liste des utilisateurs](#list-users)
+ [Afficher ou modifier les informations de l'utilisateur](#view-user-details)
+ [Suppression d'un utilisateur](#delete-user)
+ [Ajouter une clé publique SSH](#add-user-ssh-key)
+ [Supprimer la clé publique SSH](#delete-user-ssh-key)
**Pour trouver la liste de vos utilisateurs**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Sélectionnez **Serveurs** dans le volet de navigation pour afficher la page **Serveurs**.
1. Choisissez l'identifiant dans la colonne **ID du serveur** pour afficher la page de **détails du serveur**.
1. Sous **Utilisateurs**, consultez la liste des utilisateurs.
**Pour afficher ou modifier les informations de l'utilisateur**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Sélectionnez **Serveurs** dans le volet de navigation pour afficher la page **Serveurs**.
1. Choisissez l'identifiant dans la colonne **ID du serveur** pour afficher la page de **détails du serveur**.
1. Sous **Utilisateurs**, choisissez un nom d'utilisateur pour afficher la page de **détails de l'utilisateur**.
Vous pouvez modifier les propriétés de l'utilisateur sur cette page en choisissant **Modifier**.
1. Sur la page **Détails des utilisateurs**, choisissez **Modifier** à côté de **Configuration utilisateur**.
![\[Image montrant l'écran permettant de modifier la configuration d'un utilisateur\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/edit-user-details-page-user-config.png)
1. Sur la page **Modifier la configuration**, pour **Access**, choisissez le rôle IAM que vous avez créé précédemment et qui donne accès à votre compartiment Amazon S3.
Vous avez créé ce rôle IAM à l'aide de la procédure décrite dans [Création d'un rôle et d'une politique IAM](requirements-roles.md). Ce rôle IAM inclut une politique IAM qui permet d'accéder à votre compartiment Amazon S3. Cela inclut également une relation de confiance avec le AWS Transfer Family service, définie dans une autre politique IAM.
1. (Facultatif) Dans le champ **Politique**, sélectionnez l'une des options suivantes :
+ **Aucun**
+ **Politique existante**
+ **Sélectionnez une politique dans IAM** pour choisir une politique existante. Choisissez **View** pour voir un objet JSON contenant les détails de la politique.
Pour en savoir plus sur les règles de session, voir[Création d'un rôle et d'une politique IAM](requirements-roles.md). Pour en savoir plus sur la création d'une politique de session, consultez[Création d'une politique de session pour un compartiment Amazon S3](users-policies-session.md).
1. Pour le **répertoire personnel**, choisissez le compartiment Amazon S3 dans lequel stocker les données à transférer AWS Transfer Family. Entrez le chemin d'accès au `home` répertoire dans lequel votre utilisateur atterrit lorsqu'il se connecte à l'aide de son client.
Si vous laissez ce paramètre vide, le `root` répertoire de votre compartiment Amazon S3 est utilisé. Dans ce cas, vérifiez que votre rôle IAM donne accès à ce répertoire `root`.
**Note**
Nous vous recommandons de choisir un chemin de répertoire contenant le nom d'utilisateur de l'utilisateur, afin d'utiliser efficacement une politique de session. La politique de session limite l'accès des utilisateurs dans le compartiment Amazon S3 au `home` répertoire de cet utilisateur.
1. (Facultatif) Pour **Restreint**, cochez la case afin que vos utilisateurs ne puissent accéder à rien en dehors de ce dossier et ne puissent pas voir le nom du compartiment ou du dossier Amazon S3.
**Note**
Lorsque vous attribuez un répertoire personnel à l'utilisateur et que vous le limitez à ce répertoire personnel, cela devrait être suffisant pour verrouiller l'accès de l'utilisateur au dossier désigné. Utilisez une politique de session lorsque vous devez appliquer des contrôles supplémentaires.
1. Choisissez **Save** pour enregistrer les changements.
**Pour supprimer un utilisateur**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Sélectionnez **Serveurs** dans le volet de navigation pour afficher la page **Serveurs**.
1. Choisissez l'identifiant dans la colonne **ID du serveur** pour afficher la page de **détails du serveur**.
1. Sous **Utilisateurs**, choisissez un nom d'utilisateur pour afficher la page de **détails de l'utilisateur**.
1. Sur la page **des détails** de l'utilisateur, choisissez **Supprimer** à droite du nom d'utilisateur.
1. Dans la boîte de dialogue de confirmation qui s'affiche**delete**, entrez le mot, puis choisissez **Supprimer** pour confirmer que vous souhaitez supprimer l'utilisateur.
L'utilisateur est supprimé de la liste des **utilisateurs**.
**Pour ajouter une clé publique SSH pour un utilisateur**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Dans le volet de navigation, choisissez **Servers (Serveurs)**.
1. Choisissez l'identifiant dans la colonne **ID du serveur** pour afficher la page de **détails du serveur**.
1. Sous **Utilisateurs**, choisissez un nom d'utilisateur pour afficher la page de **détails de l'utilisateur**.
1. Choisissez **Add SSH public key (Ajouter une clé publique SSH)** pour ajouter une nouvelle clé publique SSH à un utilisateur.
**Note**
Les clés SSH ne sont utilisées que par les serveurs qui sont activés pour le protocole de transfert de fichiers (SFTP) Secure Shell (SSH). Pour plus d'informations sur la façon de générer une paire de clés SSH, consultez[Génération de clés SSH pour les utilisateurs gérés par des services](sshkeygen.md).
1. Dans **SSH public key (Clé publique SSH)**, entrez la partie clé publique SSH de la paire de clés SSH.
Votre clé est validée par le service avant que vous puissiez ajouter votre nouvel utilisateur. La clé SSH se présente sous la forme `ssh-rsa string`. Pour générer une paire de clés SSH, consultez[Génération de clés SSH pour les utilisateurs gérés par des services](sshkeygen.md).
1. Sélectionnez **Ajouter une clé**.
**Pour supprimer une clé publique SSH pour un utilisateur**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Dans le volet de navigation, choisissez **Servers (Serveurs)**.
1. Choisissez l'identifiant dans la colonne **ID du serveur** pour afficher la page de **détails du serveur**.
1. Sous **Utilisateurs**, choisissez un nom d'utilisateur pour afficher la page de **détails de l'utilisateur**.
1. Pour supprimer une clé publique, cochez la case correspondant à sa clé SSH et choisissez **Supprimer**.
# Travailler avec des fournisseurs d'identité personnalisés
AWS Transfer Family propose plusieurs options permettant aux fournisseurs d'identité personnalisés d'authentifier et d'autoriser les utilisateurs pour des transferts de fichiers sécurisés. Voici les principales approches :
+ [Solution de fournisseur d'identité personnalisée](custom-idp-toolkit.md)—Cette rubrique décrit la solution de fournisseur d'identité personnalisé Transfer Family, à l'aide d'une boîte à outils hébergée dans GitHub.
**Note**
Dans la plupart des cas d'utilisation, il s'agit de l'option recommandée. Plus précisément, si vous devez prendre en charge plus de 100 groupes Active Directory, la solution de fournisseur d'identité personnalisé offre une alternative évolutive sans limitation de groupe. Cette solution est décrite dans le billet de blog intitulé [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
+ [Utilisation d'Amazon API Gateway pour intégrer votre fournisseur d'identité](authentication-api-gateway.md)—Cette rubrique décrit comment utiliser une AWS Lambda fonction pour soutenir une méthode Amazon API Gateway.
Vous pouvez fournir une RESTful interface avec une seule méthode Amazon API Gateway. Transfer Family utilise cette méthode pour se connecter à votre fournisseur d'identité, qui authentifie et autorise vos utilisateurs à accéder à Amazon S3 ou Amazon EFS. Utilisez cette option si vous avez besoin d'une RESTful API pour intégrer votre fournisseur d'identité ou si vous AWS WAF souhaitez tirer parti de ses capacités de blocage géographique ou de limitation de débit des demandes. Pour en savoir plus, consultez [Utilisation d'Amazon API Gateway pour intégrer votre fournisseur d'identité](authentication-api-gateway.md).
+ [Approches dynamiques de gestion des autorisations](dynamic-permission-management.md)—Cette rubrique décrit les approches permettant de gérer les autorisations des utilisateurs de manière dynamique à l'aide de politiques de session.
Pour authentifier vos utilisateurs, vous pouvez utiliser votre fournisseur d'identité existant avec AWS Transfer Family. Vous intégrez votre fournisseur d'identité à l'aide d'une AWS Lambda fonction qui authentifie et autorise vos utilisateurs à accéder à Amazon S3 ou Amazon Elastic File System (Amazon EFS). Pour en savoir plus, consultez [Utilisation AWS Lambda pour intégrer votre fournisseur d'identité](custom-lambda-idp.md). Vous pouvez également accéder à CloudWatch des graphiques pour des indicateurs tels que le nombre de fichiers et d'octets transférés dans la console de AWS Transfer Family gestion, ce qui vous permet de surveiller les transferts de fichiers à l'aide d'un tableau de bord centralisé.
+ Transfer Family propose un article de blog et un atelier qui vous guideront dans la création d'une solution de transfert de fichiers. Cette solution s'appuie sur les SFTP/FTPS points de terminaison gérés et sur Amazon Cognito et DynamoDB AWS Transfer Family pour la gestion des utilisateurs.
Le billet de blog est disponible sur [Utilisation d'Amazon Cognito en tant que fournisseur d'identité avec Amazon AWS Transfer Family S3](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/). Vous pouvez consulter les détails de l'atelier [ici](https://catalog.workshops.aws/transfer-family-sftp/en-US).
**Note**
Pour les fournisseurs d'identité personnalisés, le nom d'utilisateur doit comporter au moins 3 caractères et au maximum 100 caractères. Vous pouvez utiliser les caractères suivants dans le nom d'utilisateur : a—z, A-Z, 0—9, trait de soulignement « \$1 », tiret « - », point «. » et signe « @». Le nom d'utilisateur ne peut pas commencer par un tiret « - », un point «. » ou par le signe « @».
Lorsque vous implémentez un fournisseur d'identité personnalisé, tenez compte des meilleures pratiques suivantes :
+ Déployez la solution dans la même Compte AWS région que vos serveurs Transfer Family.
+ Mettez en œuvre le principe du moindre privilège lors de la configuration des rôles et des politiques IAM.
+ Utilisez des fonctionnalités telles que la liste des adresses IP autorisées et la journalisation standardisée pour renforcer la sécurité.
+ Testez minutieusement votre fournisseur d'identité personnalisé dans un environnement hors production avant le déploiement.
**Topics**
+ [Solution de fournisseur d'identité personnalisée](custom-idp-toolkit.md)
+ [Utilisation AWS Lambda pour intégrer votre fournisseur d'identité](custom-lambda-idp.md)
+ [Utilisation d'Amazon API Gateway pour intégrer votre fournisseur d'identité](authentication-api-gateway.md)
+ [Utilisation de plusieurs méthodes d'authentification](custom-idp-mfa.md)
+ [IPv6 support pour les fournisseurs d'identité personnalisés](custom-idp-ipv6.md)
# Solution de fournisseur d'identité personnalisée
La solution de fournisseur d'identité AWS Transfer Family personnalisé est une solution modulaire de fournisseur d'identité personnalisé qui répond à de nombreux cas d'utilisation courants d'authentification et d'autorisation rencontrés par les entreprises lors de la mise en œuvre du service. Cette solution fournit une base réutilisable pour la mise en œuvre de fournisseurs d'identité personnalisés avec une configuration de session par utilisateur granulaire et sépare les logiques d'authentification et d'autorisation, offrant ainsi une easy-to-maintain base flexible pour différents cas d'utilisation.
Avec la solution de fournisseur d'identité AWS Transfer Family personnalisé, vous pouvez traiter les cas d'utilisation courants de l'authentification et de l'autorisation en entreprise. Cette solution modulaire offre :
+ Une base réutilisable pour la mise en œuvre de fournisseurs d'identité personnalisés
+ Configuration granulaire des sessions par utilisateur
+ Logique d'authentification et d'autorisation séparées
## Détails de mise en œuvre de la boîte à outils d'identité personnalisée
La solution fournit une base flexible et maintenable pour différents cas d'utilisation. Pour commencer, consultez le kit d'outils sur [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family), puis suivez les instructions de déploiement de la section [Getting started](https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp#getting-started).
![\[Schéma d'architecture de la boîte à outils personnalisée du fournisseur d'identité disponible dans GitHub.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/custom-idp-solution-high-level-architecture.png)
**Note**
Si vous avez déjà utilisé des modèles et des exemples de fournisseurs d'identité personnalisés, envisagez plutôt d'adopter cette solution. À l'avenir, les modules spécifiques aux fournisseurs seront standardisés sur cette solution. Une maintenance continue et des améliorations de fonctionnalités seront appliquées à cette solution.
Cette solution contient des modèles standard pour implémenter un fournisseur personnalisé qui prend en compte les détails, notamment la journalisation et l'endroit où stocker les métadonnées de session supplémentaires nécessaires AWS Transfer Family, telles que le `HomeDirectoryDetails` paramètre. Cette solution fournit une base réutilisable pour la mise en œuvre de fournisseurs d'identité personnalisés avec une configuration de session par utilisateur granulaire, et dissocie la logique d'authentification du fournisseur d'identité de la logique réutilisable qui crée une configuration qui est renvoyée à Transfer Family pour terminer l'authentification et établir les paramètres de la session.
Le code et les ressources de support de cette solution sont disponibles sur [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family).
La boîte à outils contient les fonctionnalités suivantes :
+ Un [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam)modèle qui fournit les ressources nécessaires. Vous pouvez éventuellement déployer et configurer Amazon API Gateway pour l'intégrer AWS WAF, comme décrit dans le billet de blog [Securing AWS Transfer Family with AWS Web Application Firewall and Amazon API Gateway](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/).
+ Un schéma [Amazon DynamoDB](https://aws.amazon.com/dynamodb) pour stocker les métadonnées de configuration relatives aux fournisseurs d'identité, y compris les paramètres de session utilisateur `HomeDirectoryDetails` tels que`Role`, et. `Policy`
+ Une approche modulaire qui vous permet d'ajouter de nouveaux fournisseurs d'identité à la solution à l'avenir, sous forme de modules.
+ Récupération d'attributs : récupérez éventuellement les attributs du rôle IAM et du profil POSIX (UID et GID) auprès des fournisseurs d'identité pris en charge, notamment AD, LDAP et Okta.
+ Support pour plusieurs fournisseurs d'identité connectés à un seul serveur Transfer Family et à plusieurs serveurs Transfer Family utilisant le même déploiement de la solution.
+ Contrôle intégré des listes d'adresses IP autorisées, telles que les listes d'adresses IP autorisées qui peuvent éventuellement être configurées par utilisateur ou par fournisseur d'identité.
+ Journalisation détaillée avec niveau de journalisation configurable et support de suivi pour faciliter le dépannage.
Avant de commencer à déployer la solution de fournisseur d'identité personnalisé, vous devez disposer des AWS ressources suivantes.
+ Un Amazon Virtual Private Cloud (VPC) avec des sous-réseaux privés, avec une connectivité Internet via une passerelle NAT ou un point de terminaison de passerelle DynamoDB.
+ Autorisations IAM appropriées pour effectuer les tâches suivantes :
+ Déployez le `custom-idp.yaml` CloudFormation modèle,
+ Créez des AWS CodePipeline projets
+ Créez des AWS CodeBuild projets
+ Création de rôles et de politiques IAM
**Important**
Vous devez déployer la solution sur celui-ci Compte AWS , Région AWS qui contient vos serveurs Transfer Family cibles.
## Fournisseurs d'identité pris en charge
La liste suivante contient des informations sur les fournisseurs d'identité pris en charge par la solution de fournisseur d'identité personnalisée.
| Fournisseur | Flux de mots de passe | Flux de clés publiques | Multifactoriel | Récupération d'attributs | Détails |
| --- | --- | --- | --- | --- | --- |
| Active Directory et LDAP | Oui | Oui | Non | Oui | La vérification de l'utilisateur peut être effectuée dans le cadre du flux d'authentification par clé publique. |
| Argon2 (hachage local) | Oui | Non | Non | Non | Les hachages Argon2 sont stockés dans le dossier utilisateur pour les cas d'utilisation de l'authentification « locale » basée sur un mot de passe. |
| Amazon Cognito | Oui | Non | Oui\$1 | Non | Authentification multifactorielle basée sur le temps uniquement par mot de passe à usage unique (TOTP). \$1L'authentification MFA par SMS n'est pas prise en charge. |
| Entra ID (anciennement Azure AD) | Oui | Non | Non | Non | |
| Okta | Oui | Oui | Oui\$1 | Oui | MFA basé sur TOTP uniquement. |
| Clé publique | Non | Oui | Non | Non | Les clés publiques sont stockées dans le dossier utilisateur de DynamoDB. |
| Secrets Manager | Oui | Oui | Non | Non | |
# Utilisation AWS Lambda pour intégrer votre fournisseur d'identité
Cette rubrique explique comment créer une AWS Lambda fonction qui se connecte à votre fournisseur d'identité personnalisé. Vous pouvez utiliser n'importe quel fournisseur d'identité personnalisé, tel qu'Okta, Secrets Manager OneLogin, ou un magasin de données personnalisé incluant une logique d'autorisation et d'authentification.
Dans la plupart des cas d'utilisation, la méthode recommandée pour configurer un fournisseur d'identité personnalisé consiste à utiliser le[Solution de fournisseur d'identité personnalisée](custom-idp-toolkit.md).
**Note**
Avant de créer un serveur Transfer Family qui utilise Lambda comme fournisseur d'identité, vous devez créer la fonction. Pour obtenir un exemple de fonction Lambda, consultez [Exemples de fonctions Lambda](#lambda-auth-examples). Vous pouvez également déployer une CloudFormation pile qui utilise l'un des[Modèles de fonctions Lambda](#lambda-idp-templates). Assurez-vous également que votre fonction Lambda utilise une politique basée sur les ressources qui fait confiance à Transfer Family. Pour un exemple de politique, consultez [Politique basée sur les ressources Lambda](#lambda-resource-policy).
1. Ouvrez la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/).
1. Choisissez **Create server** pour ouvrir la page **Create server**. Pour **Choisir un fournisseur d'identité**, choisissez le **fournisseur d'identité personnalisé**, comme illustré dans la capture d'écran suivante.
![\[La section de console Choisissez un fournisseur d'identité avec le fournisseur d'identité personnalisé sélectionné. La valeur par défaut est également sélectionnée, à savoir que les utilisateurs peuvent s'authentifier à l'aide de leur mot de passe ou de leur clé.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/custom-lambda-console.png)
**Note**
Le choix des méthodes d'authentification n'est disponible que si vous activez le protocole SFTP pour votre serveur Transfer Family.
1. Assurez-vous que la valeur par défaut, **Utiliser AWS Lambda pour connecter votre fournisseur d'identité**, est sélectionnée.
1. Pour **AWS Lambda fonction**, choisissez le nom de votre fonction Lambda.
1. Remplissez les cases restantes, puis choisissez **Create server**. Pour plus de détails sur les étapes restantes de création d'un serveur, consultez[Configuration d'un point de terminaison de serveur SFTP, FTPS ou FTP](tf-server-endpoint.md).
## Politique basée sur les ressources Lambda
Vous devez disposer d'une politique qui fait référence au serveur Transfer Family et à Lambda ARNs. Par exemple, vous pouvez utiliser la politique suivante avec votre fonction Lambda qui se connecte à votre fournisseur d'identité. La politique est ignorée au format JSON sous forme de chaîne.
****
```
"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\"}}}
]}"
```
**Note**
Dans l'exemple de politique ci-dessus, remplacez chacune *user input placeholder* par vos propres informations.
## Structure des messages d’événements
La structure du message d'événement envoyé par le serveur SFTP à la fonction Lambda d'autorisation pour un IDP personnalisé est la suivante.
```
{
"username": "value",
"password": "value",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
Où `username` et `password` quelles sont les valeurs des informations de connexion envoyées au serveur.
Par exemple, vous entrez la commande suivante pour vous connecter :
```
sftp bobusa@server_hostname
```
Vous êtes ensuite invité à saisir votre mot de passe :
```
Enter password:
mysecretpassword
```
Vous pouvez le vérifier à partir de votre fonction Lambda en imprimant l'événement transmis depuis la fonction Lambda. Il doit ressembler au bloc de texte suivant.
```
{
"username": "bobusa",
"password": "mysecretpassword",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
La structure des événements est similaire pour le FTP et le FTPS : la seule différence est que ces valeurs sont utilisées pour le `protocol` paramètre, plutôt que SFTP.
## Fonctions Lambda pour l'authentification
Pour implémenter différentes stratégies d'authentification, modifiez la fonction Lambda. Pour répondre aux besoins de votre application, vous pouvez déployer une CloudFormation pile. Pour plus d'informations sur Lambda, consultez le [guide du AWS Lambda développeur](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou la création de fonctions [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) avec Node.js.
**Topics**
+ [Valeurs Lambda valides](#lambda-valid-values)
+ [Exemples de fonctions Lambda](#lambda-auth-examples)
+ [Tester votre configuration](#authentication-test-configuration)
+ [Modèles de fonctions Lambda](#lambda-idp-templates)
### Valeurs Lambda valides
Le tableau suivant décrit en détail les valeurs acceptées par Transfer Family pour les fonctions Lambda utilisées par les fournisseurs d'identité personnalisés.
| Value | Description | Obligatoire |
| --- | --- | --- |
| `Role` | Spécifie le nom de ressource Amazon (ARN) du rôle IAM qui contrôle l'accès de vos utilisateurs à votre compartiment Amazon S3 ou à votre système de fichiers Amazon EFS. Les politiques associées à ce rôle déterminent le niveau d'accès que vous souhaitez fournir à vos utilisateurs lors du transfert de fichiers vers et depuis votre système de fichiers Amazon S3 ou Amazon EFS. Le rôle IAM doit également contenir une relation d'approbation qui permet au serveur d'accéder à vos ressources lors du traitement des demandes de transfert de votre utilisateur. Pour plus de détails sur l'établissement d'une relation de confiance, voir[Étape 1 : Établir une relation d'approbation](requirements-roles.md#establish-trust-transfer). | Obligatoire |
| `PosixProfile` | L'identité POSIX complète, y compris l'ID utilisateur (`Uid`), l'ID de groupe (`Gid`) et tout groupe secondaire IDs (`SecondaryGids`), qui contrôle l'accès de vos utilisateurs à vos systèmes de fichiers Amazon EFS. Les autorisations POSIX définies sur les fichiers et répertoires de votre système de fichiers déterminent le niveau d'accès accordé à vos utilisateurs lors du transfert de fichiers depuis et vers vos systèmes de fichiers Amazon EFS. | Nécessaire pour le stockage de sauvegarde Amazon EFS |
| `PublicKeys` | Liste des valeurs de clé publique SSH valides pour cet utilisateur. Une liste vide indique qu'il ne s'agit pas d'un identifiant valide. Ne doit pas être renvoyé lors de l'authentification du mot de passe. | Facultatif |
| `Policy` | Une politique de session pour votre utilisateur afin que vous puissiez utiliser le même rôle IAM pour plusieurs utilisateurs. Cette stratégie étend l'accès de l'utilisateur à des parties de son compartiment Amazon S3. Pour plus d'informations sur l'utilisation des politiques de session avec des fournisseurs d'identité personnalisés, consultez les exemples de politiques de session présentés dans cette rubrique. | Facultatif |
| `HomeDirectoryType` | Le type de répertoire (dossier) de destination du répertoire de base de vos utilisateurs lorsqu'ils se connectent au serveur. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/custom-lambda-idp.html) | Facultatif |
| `HomeDirectoryDetails` | Des mappages de répertoires logiques qui spécifient les chemins et clés Amazon S3 ou Amazon EFS qui doivent être visibles par votre utilisateur et la manière dont vous souhaitez les rendre visibles. Vous devez spécifier la `Target` paire `Entry` et, qui `Entry` indique comment le chemin est rendu visible et correspond `Target` au chemin Amazon S3 ou Amazon EFS réel. | Obligatoire s'`HomeDirectoryType`il a une valeur de `LOGICAL` |
| `HomeDirectory` | Le répertoire de destination d'un utilisateur lorsqu'il se connecte au serveur à l'aide du client. Le format dépend de votre backend de stockage : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/custom-lambda-idp.html) Le nom du compartiment ou l'ID du système de fichiers Amazon EFS doit être inclus dans le chemin. L'omission de ces informations entraînera des erreurs « Fichier introuvable » lors des transferts de fichiers. | Facultatif |
**Note**
`HomeDirectoryDetails`est une représentation sous forme de chaîne d'une carte JSON. Cela contraste avec un véritable objet de carte JSON et `PublicKeys` un tableau JSON de chaînes. `PosixProfile` Consultez les exemples de code pour les détails spécifiques au langage.
**HomeDirectory Exigences relatives au format**
Lorsque vous utilisez le `HomeDirectory` paramètre, assurez-vous d'inclure le format de chemin complet :
**Pour le stockage Amazon S3 :** incluez toujours le nom du compartiment dans le format `/bucket-name/path`
**Pour le stockage Amazon EFS :** incluez toujours l'ID du système de fichiers dans le format `/fs-12345/path`
L'une des causes fréquentes des erreurs « Fichier introuvable » est l'omission du nom du compartiment ou de l'ID du système de fichiers EFS dans le `HomeDirectory` chemin. Le réglage `HomeDirectory` sur « Juste `/` sans l'identifiant de stockage » entraînera la réussite de l'authentification, mais l'échec des opérations sur les fichiers.
### Exemples de fonctions Lambda
Cette section présente quelques exemples de fonctions Lambda, à la fois en NodeJS et en Python.
**Note**
Dans ces exemples, l'utilisateur, le rôle, le profil POSIX, le mot de passe et les détails du répertoire de base sont tous des exemples et doivent être remplacés par vos valeurs réelles.
------
#### [ Logical home directory, NodeJS ]
[L'exemple de fonction NodeJS suivant fournit les informations relatives à un utilisateur disposant d'un répertoire de base logique.](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 ]
L'exemple de fonction NodeJS suivant fournit les informations relatives à un utilisateur qui possède un répertoire de base basé sur un chemin.
```
// 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 ]
L'exemple de fonction Python suivant fournit les informations relatives à un utilisateur disposant d'un [répertoire de base logique](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 ]
L'exemple de fonction Python suivant fournit les informations relatives à un utilisateur qui possède un répertoire de base basé sur un chemin.
```
# 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
```
------
### Tester votre configuration
Après avoir créé votre fournisseur d'identité personnalisé, vous devez tester votre configuration.
------
#### [ Console ]
**Pour tester votre configuration à l'aide de la AWS Transfer Family console**
1. Ouvrez la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/).
1. Sur la page **Serveurs**, choisissez votre nouveau serveur, sélectionnez **Actions**, puis sélectionnez **Test**.
1. Entrez le texte du **nom d'utilisateur** et du **mot de passe** que vous avez définis lors du déploiement de la CloudFormation pile. Si vous avez conservé les options par défaut, le nom d'utilisateur est `myuser` et le mot de passe est`MySuperSecretPassword`.
1. Choisissez le **protocole du serveur** et entrez l'adresse IP de l'adresse **IP source**, si vous les avez définies lors du déploiement de la CloudFormation pile.
------
#### [ CLI ]
**Pour tester votre configuration à l'aide de la AWS CLI**
1. Exécutez la commande [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html). Remplacez chacune `user input placeholder` par vos propres informations, comme décrit dans les étapes suivantes.
```
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. Entrez l'ID du serveur.
1. Entrez le nom d'utilisateur et le mot de passe que vous avez définis lors du déploiement de la CloudFormation pile. Si vous avez conservé les options par défaut, le nom d'utilisateur est `myuser` et le mot de passe est`MySuperSecretPassword`.
1. Entrez le protocole du serveur et l'adresse IP source, si vous les avez définis lors du déploiement de la CloudFormation pile.
------
Si l'authentification de l'utilisateur réussit, le test renvoie une réponse `StatusCode: 200` HTTP, une chaîne vide `Message: ""` (qui contiendrait la raison de l'échec dans le cas contraire) et un `Response` champ.
**Note**
Dans l'exemple de réponse ci-dessous, le `Response` champ est un objet JSON qui a été « stringifié » (converti en une chaîne JSON plate utilisable dans un programme) et contient les détails des rôles et autorisations de l'utilisateur.
```
{
"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": ""
}
```
### Modèles de fonctions Lambda
Vous pouvez déployer une CloudFormation pile qui utilise une fonction Lambda pour l'authentification. Nous proposons plusieurs modèles qui authentifient et autorisent vos utilisateurs à l'aide de leurs identifiants de connexion. Vous pouvez modifier ces modèles ou ce AWS Lambda code pour personnaliser davantage l'accès des utilisateurs.
**Note**
Vous pouvez créer un AWS Transfer Family serveur compatible FIPS en CloudFormation spécifiant une politique de sécurité compatible FIPS dans votre modèle. Les politiques de sécurité disponibles sont décrites dans [Politiques de sécurité pour les AWS Transfer Family serveurs](security-policies.md)
**Pour créer une CloudFormation pile à utiliser pour l'authentification**
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Suivez les instructions pour déployer une CloudFormation pile à partir d'un modèle existant dans la section [Sélection d'un modèle de pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) dans le *guide de AWS CloudFormation l'utilisateur*.
1. Utilisez l'un des modèles suivants pour créer une fonction Lambda à utiliser pour l'authentification dans Transfer Family.
+ [Modèle de pile classique (Amazon Cognito)](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml)
Un modèle de base pour créer un AWS Lambda à utiliser en tant que fournisseur d'identité personnalisé dans AWS Transfer Family. Il s'authentifie auprès d'Amazon Cognito pour l'authentification par mot de passe et les clés publiques sont renvoyées depuis un compartiment Amazon S3 si l'authentification par clé publique est utilisée. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent.
+ [AWS Secrets Manager modèle de pile](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml)
Modèle de base à utiliser AWS Lambda avec un AWS Transfer Family serveur pour intégrer Secrets Manager en tant que fournisseur d'identité. Il s'authentifie par le biais d'une entrée au AWS Secrets Manager format`aws/transfer/server-id/username`. En outre, le secret doit contenir les paires clé-valeur pour toutes les propriétés utilisateur renvoyées à Transfer Family. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent.
+ Modèle de [pile Okta : modèle](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml) de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Okta en tant que fournisseur d'identité personnalisé.
+ Modèle de [pile Okta-MFA : modèle](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml) de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Okta, avec authentification multifactorielle, en tant que fournisseur d'identité personnalisé.
+ [Modèle Azure Active Directory](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml) : les détails de cette pile sont décrits dans le billet de blog [Authentication to AWS Transfer Family with Azure Active Directory et AWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/).
Une fois la pile déployée, vous pouvez consulter les détails la concernant dans l'onglet **Sorties** de la CloudFormation console.
Le déploiement de l'une de ces piles est le moyen le plus simple d'intégrer un fournisseur d'identité personnalisé dans le flux de travail Transfer Family.
# Utilisation d'Amazon API Gateway pour intégrer votre fournisseur d'identité
Cette rubrique décrit comment utiliser une AWS Lambda fonction pour sauvegarder une méthode API Gateway. Utilisez cette option si vous avez besoin d'une RESTful API pour intégrer votre fournisseur d'identité ou si vous AWS WAF souhaitez tirer parti de ses capacités de blocage géographique ou de limitation de débit des demandes.
Dans la plupart des cas d'utilisation, la méthode recommandée pour configurer un fournisseur d'identité personnalisé consiste à utiliser le[Solution de fournisseur d'identité personnalisée](custom-idp-toolkit.md).
**Limitations liées à l'utilisation d'une API Gateway pour intégrer votre fournisseur d'identité**
+ Cette configuration ne prend pas en charge les domaines personnalisés.
+ Cette configuration ne prend pas en charge une URL API Gateway privée.
Si vous avez besoin de l'une ou l'autre de ces options, vous pouvez utiliser Lambda comme fournisseur d'identité, sans API Gateway. Pour en savoir plus, consultez [Utilisation AWS Lambda pour intégrer votre fournisseur d'identité](custom-lambda-idp.md).
## Authentification à l'aide d'une méthode API Gateway
Vous pouvez créer une méthode API Gateway à utiliser en tant que fournisseur d'identité pour Transfer Family. Cette approche constitue un moyen hautement sécurisé de créer et de fournir APIs. Avec API Gateway, vous pouvez créer un point de terminaison HTTPS afin que toutes les opérations d'API entrantes soient transmises avec une sécurité accrue. Pour plus de détails sur le service API Gateway, consultez le [guide du développeur d'API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).
API Gateway propose une méthode d'autorisation nommée`AWS_IAM`, qui vous donne la même authentification basée sur Gestion des identités et des accès AWS (IAM) que celle AWS utilisée en interne. Si vous activez l'authentification avec`AWS_IAM`, seuls les appelants disposant d'autorisations explicites pour appeler une API peuvent accéder à la méthode API Gateway de cette API.
Pour utiliser votre méthode API Gateway en tant que fournisseur d'identité personnalisé pour Transfer Family, activez IAM pour votre méthode API Gateway. Dans le cadre de ce processus, vous fournissez un rôle IAM avec des autorisations permettant à Transfer Family d'utiliser votre passerelle.
**Note**
Pour améliorer la sécurité, vous pouvez configurer un pare-feu pour applications Web. AWS WAF est un pare-feu d'applications Web qui vous permet de surveiller les requêtes HTTP et HTTPS qui sont transmises à Amazon API Gateway. Pour en savoir plus, consultez [Ajouter un pare-feu pour applications Web](web-application-firewall.md).
**Ne pas activer la mise en cache d'API Gateway**
N'activez pas la mise en cache pour votre méthode API Gateway lorsque vous l'utilisez comme fournisseur d'identité personnalisé pour Transfer Family. La mise en cache est inappropriée et non valide pour les demandes d'authentification pour les raisons suivantes :
Chaque demande d'authentification est unique et nécessite une réponse en direct, et non une réponse en cache
La mise en cache n'apporte aucun avantage puisque Transfer Family n'envoie jamais de demandes dupliquées ou répétées à l'API Gateway.
L'activation de la mise en cache entraînera la réponse de l'API Gateway avec des données incompatibles, ce qui se traduira par des réponses non valides aux demandes d'authentification
**Pour utiliser votre méthode API Gateway pour une authentification personnalisée avec Transfer Family**
1. Créez une CloudFormation pile. Pour cela :
**Note**
Les modèles de pile ont été mis à jour pour utiliser des mots de passe BASE64 codés : pour plus de détails, voir[Améliorations apportées aux CloudFormation modèles](#base64-templates).
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Suivez les instructions pour déployer une CloudFormation pile à partir d'un modèle existant dans la section [Sélection d'un modèle de pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) dans le *guide de AWS CloudFormation l'utilisateur*.
1. Utilisez l'un des modèles de base suivants pour créer une méthode API Gateway AWS Lambda basée sur des données à utiliser en tant que fournisseur d'identité personnalisé dans Transfer Family.
+ [Modèle de pile de base](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-apig.template.yml)
Par défaut, votre méthode API Gateway est utilisée comme fournisseur d'identité personnalisé pour authentifier un seul utilisateur sur un seul serveur à l'aide d'une clé ou d'un mot de passe SSH (Secure Shell) codé en dur. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent.
+ [AWS Secrets Manager modèle de pile](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml)
Par défaut, votre méthode API Gateway s'authentifie par rapport à une entrée du format `aws/transfer/server-id/username` Secrets Manager. En outre, le secret doit contenir les paires clé-valeur pour toutes les propriétés utilisateur renvoyées à Transfer Family. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent. Pour plus d'informations, consultez le billet de blog [Activer l'authentification par mot de passe pour AWS Transfer Family l'utilisation AWS Secrets Manager](https://aws.amazon.com/blogs/storage/enable-password-authentication-for-aws-transfer-family-using-aws-secrets-manager-updated/).
+ [Modèle Okta Stack](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-apig.template.yml)
Votre méthode API Gateway s'intègre à Okta en tant que fournisseur d'identité personnalisé dans Transfer Family. Pour plus d'informations, consultez le billet de blog [Utiliser Okta comme fournisseur d'identité avec AWS Transfer Family](https://aws.amazon.com/blogs/storage/using-okta-as-an-identity-provider-with-aws-transfer-for-sftp/).
Le déploiement de l'une de ces piles est le moyen le plus simple d'intégrer un fournisseur d'identité personnalisé dans le flux de travail Transfer Family. Chaque pile utilise la fonction Lambda pour prendre en charge votre méthode d'API basée sur API Gateway. Vous pouvez ensuite utiliser votre méthode API en tant que fournisseur d'identité personnalisé dans Transfer Family. Par défaut, la fonction Lambda authentifie un seul utilisateur appelé `myuser` avec un mot de passe de. `MySuperSecretPassword` Après le déploiement, vous pouvez modifier ces informations d'identification ou mettre à jour le code de fonction Lambda pour faire quelque chose de différent.
**Important**
Nous vous recommandons de modifier les informations d'identification de l'utilisateur et du mot de passe par défaut.
Une fois la pile déployée, vous pouvez consulter les détails la concernant dans l'onglet **Sorties** de la CloudFormation console. Ces informations incluent le nom de ressource Amazon (ARN) de la pile, l'ARN du rôle IAM créé par la pile et l'URL de votre nouvelle passerelle.
**Note**
Si vous utilisez l'option de fournisseur d'identité personnalisé pour activer l'authentification par mot de passe pour vos utilisateurs, et si vous activez l'enregistrement des demandes et des réponses fourni par API Gateway, API Gateway enregistre les mots de passe de vos utilisateurs sur votre Amazon Logs. CloudWatch Nous vous déconseillons d'utiliser ce journal dans votre environnement de production. Pour plus d'informations, consultez la section [Configurer CloudWatch la journalisation des API dans API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html) dans le *Guide du développeur d'API Gateway*.
1. Vérifiez la configuration de la méthode API Gateway pour votre serveur. Pour cela :
1. Ouvrez la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/).
1. Choisissez l'**API du modèle de base Transfer Custom Identity Provider** générée par le CloudFormation modèle. Vous devrez peut-être sélectionner votre région pour voir vos passerelles.
1. Dans le volet **Ressources**, sélectionnez **GET**. La capture d'écran suivante montre la configuration correcte de la méthode.
![\[Détails de configuration de l'API, indiquant les paramètres de configuration de la méthode pour les chemins de demande et pour la chaîne de requête URL.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/apig-config-method-fields.png)
À ce stade, votre passerelle API est prête à être déployée.
1. Pour **Actions**, choisissez **Deploy API**. Pour l'**étape de déploiement**, choisissez **prod**, puis **Deploy**.
Une fois la méthode API Gateway déployée avec succès, visualisez ses performances dans **Stages** > **Détails de l'étape**, comme illustré dans la capture d'écran suivante.
**Note**
Copiez l'adresse **URL Invoke** qui apparaît en haut de l'écran. Vous en aurez peut-être besoin pour l'étape suivante.
![\[Détails de l'étape avec l'URL Invoke surlignée.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/apig-config-method-invoke.png)
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Une Transfer Family aurait dû être créée pour vous, lorsque vous avez créé la pile. Si ce n'est pas le cas, configurez votre serveur en suivant ces étapes.
1. Choisissez **Create server** pour ouvrir la page **Create server**. Pour **Choisir un fournisseur d'identité**, choisissez **Personnalisé**, puis sélectionnez **Utiliser Amazon API Gateway pour vous connecter à votre fournisseur d'identité**, comme illustré dans la capture d'écran ci-dessous.
![\[L'écran du fournisseur d'identité avec le fournisseur d'identité personnalisé sélectionné et avec l'API Gateway choisie pour la connexion à votre fournisseur d'identité.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/create-server-choose-idp-custom.png)
1. Dans la zone de texte **Provide an Amazon API Gateway URL**, collez l'adresse **URL Invoke** du point de terminaison API Gateway que vous avez créé à l'étape 3 de cette procédure.
1. Pour **Rôle**, choisissez le rôle IAM créé par le CloudFormation modèle. Ce rôle permet à Transfer Family d'invoquer votre méthode de passerelle d'API.
Le rôle d'invocation contient le nom de CloudFormation pile que vous avez sélectionné pour la pile que vous avez créée à l'étape 1. Il a le format suivant :`CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI`.
1. Remplissez les cases restantes, puis choisissez **Create server**. Pour plus de détails sur les étapes restantes de création d'un serveur, consultez[Configuration d'un point de terminaison de serveur SFTP, FTPS ou FTP](tf-server-endpoint.md).
## Implémentation de votre méthode API Gateway
Pour créer un fournisseur d'identité personnalisé pour Transfer Family, votre méthode API Gateway doit implémenter une méthode unique dont le chemin de ressource est de`/servers/serverId/users/username/config`. Les `username` valeurs `serverId` et proviennent du chemin de la RESTful ressource. Ajoutez également `sourceIp` et `protocol` en tant que **paramètres de chaîne de requête URL** dans la **demande de méthode**, comme indiqué dans l'image suivante.
![\[L'écran Resources de l'API Gateway affichant les détails de la GET méthode.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/apig-config-method-request.png)
**Note**
Le nom d'utilisateur doit comporter au minimum 3 caractères et au maximum 100 caractères. Vous pouvez utiliser les caractères suivants dans le nom d'utilisateur : a—z, A-Z, 0—9, trait de soulignement « \$1 », tiret « - », point «. » et signe « @». Le nom d'utilisateur ne peut pas commencer par un tiret « - », un point «. » ou par le signe « @».
Si Transfer Family tente d'authentifier votre utilisateur par mot de passe, le service fournit un champ d'`Password:`en-tête. En l'absence d'`Password:`en-tête, Transfer Family tente de s'authentifier par clé publique pour authentifier votre utilisateur.
Lorsque vous utilisez un fournisseur d'identité pour authentifier et autoriser les utilisateurs finaux, en plus de valider leurs informations d'identification, vous pouvez autoriser ou refuser les demandes d'accès en fonction des adresses IP des clients utilisés par vos utilisateurs finaux. Vous pouvez utiliser cette fonctionnalité pour garantir que les données stockées dans vos compartiments S3 ou dans votre système de fichiers Amazon EFS ne sont accessibles via les protocoles pris en charge qu'à partir d'adresses IP que vous avez spécifiées comme fiables. Pour activer cette fonctionnalité, vous devez l'inclure `sourceIp` dans la chaîne de requête.
Si plusieurs protocoles sont activés pour votre serveur et que vous souhaitez fournir un accès en utilisant le même nom d'utilisateur sur plusieurs protocoles, vous pouvez le faire à condition que les informations d'identification spécifiques à chaque protocole aient été configurées dans votre fournisseur d'identité. Pour activer cette fonctionnalité, vous devez inclure la `protocol` valeur dans le chemin de la RESTful ressource.
Votre méthode API Gateway doit toujours renvoyer le code d'état HTTP`200`. Tout autre code d'état HTTP indique qu'une erreur s'est produite lors de l'accès à l'API.
**Exemple de réponse Amazon S3**
Le corps de réponse d'exemple est un document JSON au format suivant pour 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"
}
```
**Note**
La politique est ignorée au format JSON sous forme de chaîne. Par exemple :
****
```
"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\"}]
}"
```
L'exemple de réponse suivant montre qu'un utilisateur possède un type de répertoire de base logique.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-s3",
"HomeDirectoryType":"LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/amzn-s3-demo-bucket1\"}]",
"PublicKeys":[""]
}
```
**Exemple de réponse Amazon EFS**
Le corps de réponse d'exemple est un document JSON au format suivant pour 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"
}
```
Le `Role` champ indique que l'authentification a été réussie. Lors de l'authentification par mot de passe (lorsque vous fournissez un `Password:` en-tête), vous n'avez pas besoin de fournir de clés publiques SSH. Si un utilisateur ne peut pas être authentifié, par exemple si le mot de passe est incorrect, votre méthode doit renvoyer une réponse non `Role` définie. Un exemple d'une telle réponse est un objet JSON vide.
L'exemple de réponse suivant montre un utilisateur dont le type de répertoire de base est logique.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-efs",
"HomeDirectoryType": "LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/faa1a123\"}]",
"PublicKeys":[""],
"PosixProfile":{"Uid":65534,"Gid":65534}
}
```
Vous pouvez inclure des politiques utilisateur dans la fonction Lambda au format JSON. Pour plus d'informations sur la configuration des politiques utilisateur dans Transfer Family, consultez[Gestion des contrôles d’accès](users-policies.md).
## Fonction Lambda par défaut
Pour implémenter différentes stratégies d'authentification, modifiez la fonction Lambda utilisée par votre passerelle. Pour vous aider à répondre aux besoins de votre application, vous pouvez utiliser les exemples de fonctions Lambda suivants dans le fichier Node.js. Pour plus d'informations sur Lambda, consultez le [guide du AWS Lambda développeur](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou la création de fonctions [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) avec Node.js.
L'exemple de fonction Lambda suivant prend votre nom d'utilisateur, votre mot de passe (si vous effectuez une authentification par mot de passe), l'ID du serveur, le protocole et l'adresse IP du client. Vous pouvez utiliser une combinaison de ces entrées pour rechercher votre fournisseur d'identité et déterminer si la connexion doit être acceptée.
**Note**
Si plusieurs protocoles sont activés pour votre serveur et que vous souhaitez fournir un accès en utilisant le même nom d'utilisateur sur plusieurs protocoles, vous pouvez le faire à condition que les informations d'identification spécifiques au protocole aient été configurées dans votre fournisseur d'identité.
Pour le protocole de transfert de fichiers (FTP), nous recommandons de conserver des informations d'identification distinctes pour le protocole de transfert de fichiers (SFTP) Secure Shell (SSH) et le protocole de transfert de fichiers via SSL (FTPS). Nous recommandons de conserver des informations d'identification distinctes pour le protocole FTP car, contrairement au protocole SFTP et au protocole FTPS, le protocole FTP transmet les informations d'identification en texte clair. En isolant les informations d'identification FTP de celles du protocole SFTP ou FTPS, si les informations d'identification FTP sont partagées ou exposées, vos charges de travail utilisant le protocole SFTP ou FTPS restent sécurisées.
Cet exemple de fonction renvoie le rôle et les détails du répertoire de base logique, ainsi que les clés publiques (si elle effectue une authentification par clé publique).
Lorsque vous créez des utilisateurs gérés par des services, vous définissez leur répertoire de base, qu'il soit logique ou physique. De même, nous avons besoin des résultats de la fonction Lambda pour transmettre la structure de répertoire physique ou logique souhaitée par l'utilisateur. Les paramètres que vous définissez dépendent de la valeur du [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)champ.
+ `HomeDirectoryType`défini sur `PATH` : le `HomeDirectory` champ doit alors être un préfixe de compartiment Amazon S3 absolu ou un chemin absolu Amazon EFS visible par vos utilisateurs.
+ `HomeDirectoryType`set to `LOGICAL` — *Ne définit aucun* `HomeDirectory` champ. Nous avons plutôt défini un `HomeDirectoryDetails` champ qui fournit les Entry/Target mappages souhaités, similaires aux valeurs décrites dans le [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)paramètre pour les utilisateurs gérés par des services.
Les exemples de fonctions sont répertoriés dans[Exemples de fonctions Lambda](custom-lambda-idp.md#lambda-auth-examples).
## Fonction Lambda à utiliser avec AWS Secrets Manager
Pour l'utiliser AWS Secrets Manager comme fournisseur d'identité, vous pouvez utiliser la fonction Lambda dans l'exemple de modèle CloudFormation . La fonction Lambda interroge le service Secrets Manager avec vos informations d'identification et, en cas de succès, renvoie un secret désigné. Pour plus d’informations sur Secrets Manager, consultez le [Guide de l’utilisateur AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Pour télécharger un exemple de CloudFormation modèle utilisant cette fonction Lambda, accédez au compartiment [Amazon S3 fourni par](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml). AWS Transfer Family
## Améliorations apportées aux CloudFormation modèles
Des améliorations ont été apportées à l'interface API Gateway dans les CloudFormation modèles publiés. Les modèles utilisent désormais des mots de passe BASE64 codés avec l'API Gateway. Vos déploiements existants continuent de fonctionner sans cette amélioration, mais n'autorisent pas les mots de passe contenant des caractères autres que le jeu de caractères US-ASCII de base.
Les modifications apportées au modèle pour activer cette fonctionnalité sont les suivantes :
+ La `GetUserConfigRequest AWS::ApiGateway::Method` ressource doit avoir ce `RequestTemplates` code (la ligne en italique est la ligne mise à jour)
```
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')"
}
```
+ Le `RequestParameters` nom de la `GetUserConfig` ressource doit changer pour utiliser l'`PasswordBase64`en-tête (la ligne en italique est la ligne mise à jour) :
```
RequestParameters:
method.request.header.PasswordBase64: false
method.request.querystring.protocol: false
method.request.querystring.sourceIp: false
```
**Pour vérifier si le modèle de votre stack est le plus récent**
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Dans la liste des piles, choisissez votre pile.
1. Dans le panneau de détails, choisissez l'onglet **Modèle**.
1. Recherchez les éléments suivants :
+ Recherchez `RequestTemplates` et assurez-vous d'avoir cette ligne :
```
"password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
```
+ Recherchez `RequestParameters` et assurez-vous d'avoir cette ligne :
```
method.request.header.PasswordBase64: false
```
Si les lignes mises à jour ne s'affichent pas, modifiez votre pile. Pour plus de détails sur la mise à jour de votre CloudFormation pile, consultez la section [Modification d'un modèle de pile](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-get-template.html) dans le *AWS CloudFormation guide de l'utilisateur*.
# Utilisation de plusieurs méthodes d'authentification
Le serveur Transfer Family contrôle la logique AND lorsque vous utilisez plusieurs méthodes d'authentification. Transfer Family traite cela comme deux demandes distinctes adressées à votre fournisseur d'identité personnalisé : toutefois, leur effet est combiné.
Les deux demandes doivent être renvoyées avec succès avec la bonne réponse pour permettre à l'authentification de se terminer. Transfer Family exige que les deux réponses soient complètes, ce qui signifie qu'elles contiennent tous les éléments requis (rôle, répertoire de base, politique et profil POSIX si vous utilisez Amazon EFS pour le stockage). Transfer Family exige également que la réponse au mot de passe ne contienne pas de clés publiques.
La demande de clé publique doit faire l'objet d'une réponse distincte de la part du fournisseur d'identité. Ce comportement reste inchangé lorsque vous utilisez le **mot de passe OU la clé** ou le **mot de passe ET la clé**.
Le protocole SSH/SFTP met d'abord le client logiciel au défi d'une authentification par clé publique, puis demande une authentification par mot de passe. Cette opération garantit la réussite des deux opérations avant que l'utilisateur ne soit autorisé à terminer l'authentification.
Pour les options de fournisseur d'identité personnalisées, vous pouvez spécifier l'une des options suivantes pour l'authentification.
+ **Mot de passe OU clé** : les utilisateurs peuvent s'authentifier à l'aide de leur mot de passe ou de leur clé. C’est la valeur par défaut.
+ **MOT DE PASSE UNIQUEMENT** : les utilisateurs doivent fournir leur mot de passe pour se connecter.
+ **Clé UNIQUEMENT** : les utilisateurs doivent fournir leur clé privée pour se connecter.
+ **Mot de passe ET clé** : les utilisateurs doivent fournir leur clé privée et leur mot de passe pour se connecter. Le serveur vérifie d'abord la clé, puis si la clé est valide, le système demande un mot de passe. Si la clé privée fournie ne correspond pas à la clé publique stockée, l'authentification échoue.
# IPv6 support pour les fournisseurs d'identité personnalisés
AWS Transfer Family les fournisseurs d'identité personnalisés prennent entièrement en charge IPv6 les connexions. Lorsque vous implémentez un fournisseur d'identité personnalisé, votre fonction Lambda peut recevoir et traiter des demandes d'authentification provenant à la fois de la part des IPv6 clients IPv4 et de la part des clients sans aucune configuration supplémentaire. La fonction Lambda reçoit l'adresse IP du client dans le `sourceIp` champ de la demande, qui peut être une IPv4 adresse (par exemple`203.0.113.42`) ou une IPv6 adresse (par exemple,`2001:db8:85a3:8d3:1319:8a2e:370:7348`). L'implémentation de votre fournisseur d'identité personnalisé doit gérer les deux formats d'adresse de manière appropriée.
**Important**
Si votre fournisseur d'identité personnalisé effectue une validation ou une journalisation basée sur l'adresse IP, assurez-vous que votre implémentation gère correctement les formats d' IPv6 adresse. IPv6 les adresses sont plus longues que IPv4 les adresses et utilisent un format de notation différent.
**Note**
Lorsque vous gérez des IPv6 adresses dans votre fournisseur d'identité personnalisé, assurez-vous d'utiliser des fonctions d'analyse d' IPv6 adresses appropriées plutôt que de simples comparaisons de chaînes. IPv6les adresses peuvent être représentées dans différents formats canoniques (par exemple `fd00:b600::ec2` ou`fd00:b600:0:0:0:0:0:ec2`). Utilisez les bibliothèques d' IPv6 adresses ou les fonctions appropriées dans votre langage d'implémentation pour valider et comparer correctement IPv6 les adresses.
**Example Gestion à la fois IPv4 des IPv6 adresses et des adresses dans un fournisseur d'identité personnalisé**
```
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"
}
```
Pour plus d'informations sur la mise en œuvre de fournisseurs d'identité personnalisés, consultez[Utilisation AWS Lambda pour intégrer votre fournisseur d'identité](custom-lambda-idp.md).
# Utilisation de AWS Directory Service pour Microsoft Active Directory
Vous pouvez l'utiliser AWS Transfer Family pour authentifier les utilisateurs finaux de votre transfert de fichiers à l'aide AWS Directory Service for Microsoft Active Directory de. Il permet une migration fluide des flux de transfert de fichiers qui reposent sur l'authentification Active Directory sans modifier les informations d'identification des utilisateurs finaux ni avoir besoin d'un autorisateur personnalisé.
Vous pouvez ainsi fournir aux AWS Managed Microsoft AD Directory Service utilisateurs et aux groupes un accès sécurisé via SFTP, FTPS et FTP aux données stockées dans Amazon Simple Storage Service (Amazon S3) ou Amazon Elastic File System (Amazon EFS). Si vous utilisez Active Directory pour stocker les informations d'identification de vos utilisateurs, vous pouvez désormais activer plus facilement les transferts de fichiers pour ces utilisateurs.
Vous pouvez fournir un accès aux groupes Active Directory AWS Managed Microsoft AD dans votre environnement sur site ou dans le AWS cloud à l'aide de connecteurs Active Directory. Vous pouvez donner aux utilisateurs déjà configurés dans votre environnement Microsoft Windows, que ce soit dans le AWS Cloud ou sur leur réseau local, l'accès à un AWS Transfer Family serveur qui utilise AWS Managed Microsoft AD l'identité. Le blog sur le AWS stockage contient un article qui détaille une solution pour utiliser Active Directory avec Transfer Family : [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
**Note**
AWS Transfer Family ne prend pas en charge Simple AD.
Transfer Family ne prend pas en charge les configurations Active Directory interrégionales : nous prenons uniquement en charge les intégrations Active Directory situées dans la même région que celle du serveur Transfer Family.
Transfer Family ne prend pas en charge l'utilisation d'AD Connector AWS Managed Microsoft AD ou d'AD Connector pour activer l'authentification multifactorielle (MFA) pour votre infrastructure MFA existante basée sur Radius.
AWS Transfer Family ne prend pas en charge les régions répliquées de Managed Active Directory.
Pour l'utiliser AWS Managed Microsoft AD, vous devez suivre les étapes suivantes :
1. Créez un ou plusieurs AWS Managed Microsoft AD répertoires à l'aide de la Directory Service console.
1. Utilisez la console Transfer Family pour créer un serveur utilisé AWS Managed Microsoft AD comme fournisseur d'identité.
1. Configurez l' AWS annuaire à l'aide d'un connecteur Active Directory.
1. Ajoutez l'accès depuis un ou plusieurs de vos Directory Service groupes.
1. Bien que cela ne soit pas obligatoire, nous vous recommandons de tester et de vérifier l'accès des utilisateurs.
**Topics**
+ [Avant de commencer à utiliser AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)
+ [Utilisation des domaines Active Directory](#managed-ad-realms)
+ [Choisir AWS Managed Microsoft AD comme fournisseur d'identité](#managed-ad-identity-provider)
+ [Connexion à Microsoft Active Directory sur site](#on-prem-ad)
+ [Octroi de l'accès à des groupes](#directory-services-grant-access)
+ [Tester les utilisateurs](#directory-services-test-user)
+ [Supprimer l'accès au serveur pour un groupe](#directory-services-misc)
+ [Connexion au serveur via SSH (Secure Shell)](#directory-services-ssh-procedure)
+ [Connexion AWS Transfer Family à un Active Directory autogéré à l'aide de forêts et d'approbations](#directory-services-ad-trust)
## Avant de commencer à utiliser AWS Directory Service for Microsoft Active Directory
**Note**
AWS Transfer Family a une limite par défaut de 100 groupes Active Directory par serveur. Si votre cas d'utilisation nécessite plus de 100 groupes, envisagez d'utiliser une solution de fournisseur d'identité personnalisée, comme décrit dans [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
### Fournissez un identifiant unique pour vos groupes AD
Avant de pouvoir l'utiliser AWS Managed Microsoft AD, vous devez fournir un identifiant unique pour chaque groupe de votre annuaire Microsoft AD. Pour ce faire, vous pouvez utiliser l'identifiant de sécurité (SID) de chaque groupe. Les utilisateurs du groupe que vous associez ont accès à vos ressources Amazon S3 ou Amazon EFS via les protocoles activés à l'aide de AWS Transfer Family.
Utilisez la PowerShell commande Windows suivante pour récupérer le SID d'un groupe, en le *YourGroupName* remplaçant par le nom du groupe.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
**Note**
Si vous utilisez AWS Directory Service comme fournisseur d'identité, `userPrincipalName` et si vous `SamAccountName` avez des valeurs différentes, AWS Transfer Family accepte la valeur dans`SamAccountName`. Transfer Family n'accepte pas la valeur spécifiée dans`userPrincipalName`.
### Ajoutez Directory Service des autorisations à votre rôle
Vous devez également disposer d'autorisations d' Directory Service API pour les utiliser AWS Directory Service en tant que fournisseur d'identité. Les autorisations suivantes sont requises ou suggérées :
+ `ds:DescribeDirectories`est nécessaire pour que Transfer Family puisse consulter le répertoire
+ `ds:AuthorizeApplication`est nécessaire pour ajouter une autorisation pour Transfer Family
+ `ds:UnauthorizeApplication`est suggéré de supprimer toutes les ressources créées de manière provisoire, au cas où quelque chose ne tournerait pas rond pendant le processus de création du serveur
Ajoutez ces autorisations au rôle que vous utilisez pour créer vos serveurs Transfer Family. Pour plus de détails sur ces autorisations, consultez [Autorisations d'Directory Service API : référence aux actions, aux ressources et aux conditions](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/UsingWithDS_IAM_ResourcePermissions.html).
## Utilisation des domaines Active Directory
Lorsque vous réfléchissez à la manière dont vos utilisateurs Active Directory peuvent accéder aux AWS Transfer Family serveurs, gardez à l'esprit le domaine de l'utilisateur et celui de son groupe. Idéalement, le domaine de l'utilisateur et celui de son groupe devraient correspondre. En d'autres termes, l'utilisateur et le groupe se trouvent dans le domaine par défaut, ou les deux dans le domaine de confiance. Si ce n'est pas le cas, l'utilisateur ne peut pas être authentifié par Transfer Family.
Vous pouvez tester l'utilisateur pour vous assurer que la configuration est correcte. Pour en savoir plus, consultez [Tester les utilisateurs](#directory-services-test-user). En cas de problème avec le user/group domaine, vous recevez le message d'erreur « Aucun accès associé trouvé pour les groupes d'utilisateurs ».
## Choisir AWS Managed Microsoft AD comme fournisseur d'identité
Cette section décrit comment l'utiliser AWS Directory Service for Microsoft Active Directory avec un serveur.
**À utiliser AWS Managed Microsoft AD avec Transfer Family**
1. Connectez-vous à la Directory Service console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).
Utilisez la Directory Service console pour configurer un ou plusieurs annuaires gérés. Pour plus d'informations, veuillez consulter la rubrique [AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) dans le *Guide de l'administrateur Directory Service *.
![\[La console Directory Service affiche la liste des annuaires et leurs détails.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/directory-services-AD-list.png)
1. Ouvrez la AWS Transfer Family console à [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), puis choisissez **Create server**.
1. Sur la page **Choisir des protocoles**, sélectionnez un ou plusieurs protocoles dans la liste.
**Note**
Si vous sélectionnez **FTPS**, vous devez fournir le AWS Certificate Manager certificat.
1. Pour **Choisir un fournisseur d'identité**, choisissez **AWS Directory Service**.
![\[Capture d'écran de la console montrant la section Choisir un fournisseur d'identité avec Directory Service sélectionné.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/create-server-choose-idp-directory-services.png)
1. La liste des **annuaires** contient tous les annuaires gérés que vous avez configurés. Choisissez un répertoire dans la liste, puis cliquez sur **Next**.
**Note**
Les annuaires multicomptes et partagés ne sont pas pris en charge pour AWS Managed Microsoft AD.
Pour configurer un serveur avec Directory Service comme fournisseur d'identité, vous devez ajouter des Directory Service autorisations. Pour en savoir plus, consultez [Avant de commencer à utiliser AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Pour terminer la création du serveur, appliquez l'une des procédures suivantes :
+ [Création d'un serveur compatible SFTP](create-server-sftp.md)
+ [Création d'un serveur compatible FTP](create-server-ftps.md)
+ [Création d'un serveur compatible FTP](create-server-ftp.md)
Dans ces procédures, passez à l'étape qui suit le choix d'un fournisseur d'identité.
**Important**
Vous ne pouvez pas supprimer un répertoire Microsoft AD Directory Service si vous l'avez utilisé sur un serveur Transfer Family. Vous devez d'abord supprimer le serveur, puis vous pouvez supprimer le répertoire.
## Connexion à Microsoft Active Directory sur site
Cette section décrit comment configurer un AWS annuaire à l'aide d'un AD Connector
**Pour configurer votre AWS annuaire à l'aide d'AD Connector**
1. Ouvrez la console [Directory Service](https://console.aws.amazon.com/directoryservicev2/) et sélectionnez **Directories**.
1. Sélectionnez **Configurer le répertoire**.
1. Pour le type de répertoire, choisissez **AD Connector**.
1. Sélectionnez une taille de répertoire, sélectionnez **Suivant**, puis sélectionnez votre VPC et vos sous-réseaux.
1. Sélectionnez **Suivant**, puis renseignez les champs comme suit :
+ **Nom DNS du répertoire** : entrez le nom de domaine que vous utilisez pour votre Microsoft Active Directory.
+ **Adresses IP DNS** : entrez vos adresses IP Microsoft Active Directory.
+ **Nom d'utilisateur et **mot de passe** du compte serveur** : entrez les détails du compte de service à utiliser.
1. Complétez les écrans pour créer le service d'annuaire.
L'étape suivante consiste à créer un serveur Transfer Family utilisant le protocole SFTP et le type de fournisseur d'identité **AWS Directory Service**. Dans la liste déroulante **Répertoire**, sélectionnez le répertoire que vous avez ajouté lors de la procédure précédente.
## Octroi de l'accès à des groupes
Après avoir créé le serveur, vous devez choisir les groupes du répertoire qui doivent avoir accès au chargement et au téléchargement de fichiers via les protocoles activés à l'aide de AWS Transfer Family. Pour ce faire, créez un *accès*.
**Note**
AWS Transfer Family a une limite par défaut de 100 groupes Active Directory par serveur. Si votre cas d'utilisation nécessite plus de 100 groupes, envisagez d'utiliser une solution de fournisseur d'identité personnalisée, comme décrit dans [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
**Note**
Les utilisateurs doivent appartenir *directement* au groupe auquel vous accordez l'accès. Par exemple, supposons que Bob est un utilisateur et appartient au groupe A, et que le groupe A lui-même est inclus dans le groupe B.
Si vous accordez l'accès à GroupA, Bob est autorisé à y accéder.
Si vous accordez l'accès au groupe B (et non au groupe A), Bob n'y a pas accès.
**Pour accorder l'accès à un groupe**
1. Ouvrez la AWS Transfer Family console à l'adresse [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Accédez à la page des détails de votre serveur.
1. Dans la section **Accès**, choisissez **Ajouter un accès**.
1. Entrez le SID du AWS Managed Microsoft AD répertoire auquel vous souhaitez accéder à ce serveur.
**Note**
Pour plus d'informations sur la manière de trouver le SID de votre groupe, consultez[Avant de commencer à utiliser AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Pour **Access**, choisissez un rôle Gestion des identités et des accès AWS (IAM) pour le groupe.
1. Dans la section **Stratégie**, choisissez une stratégie. Le paramètre par défaut est **Aucun**.
1. Pour le **répertoire personnel**, choisissez un compartiment Amazon S3 correspondant au répertoire personnel du groupe.
**Note**
Vous pouvez limiter les parties du bucket visibles par les utilisateurs en créant une politique de session. Par exemple, pour limiter les utilisateurs à leur propre dossier dans le `/filetest` répertoire, entrez le texte suivant dans le champ.
```
/filetest/${transfer:UserName}
```
Pour en savoir plus sur la création d'une politique de session, consultez[Création d'une politique de session pour un compartiment Amazon S3](users-policies-session.md).
1. Choisissez **Ajouter** pour créer l'association.
1. Choisissez votre serveur.
1. Choisissez **Ajouter un accès**.
1. Entrez le SID du groupe.
**Note**
Pour plus d'informations sur la façon de trouver le SID, consultez[Avant de commencer à utiliser AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Choisissez **Ajouter un accès**.
Dans la section **Accès**, les accès au serveur sont répertoriés.
![\[Console affichant la section Accès répertoriant les accès au serveur.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/accesses-list.png)
## Tester les utilisateurs
Vous pouvez vérifier si un utilisateur a accès à l' AWS Managed Microsoft AD annuaire de votre serveur.
**Note**
Un utilisateur doit appartenir exactement à un groupe (un ID externe) répertorié dans la section **Accès** de la page de **configuration du point de terminaison**. Si l'utilisateur ne fait partie d'aucun groupe, ou s'il fait partie de plusieurs groupes, il n'est pas autorisé à y accéder.
**Pour vérifier si un utilisateur spécifique a accès**
1. Sur la page de détails du serveur, choisissez **Actions**, puis sélectionnez **Test**.
1. Pour **tester le fournisseur d'identité**, entrez les informations de connexion d'un utilisateur appartenant à l'un des groupes ayant accès.
1. Sélectionnez **Tester)**.
Vous voyez un test du fournisseur d'identité réussi, indiquant que l'utilisateur sélectionné a obtenu l'accès au serveur.
![\[Capture d'écran de la console montrant la réponse réussie au test du fournisseur d'identité.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/identity-provider-test-success.png)
Si l'utilisateur appartient à plusieurs groupes ayant accès, vous recevez la réponse suivante.
```
"Response":"",
"StatusCode":200,
"Message":"More than one associated access found for user's groups."
```
## Supprimer l'accès au serveur pour un groupe
**Pour supprimer l'accès au serveur pour un groupe**
1. Sur la page de détails du serveur, choisissez **Actions**, puis sélectionnez **Supprimer l'accès**.
1. Dans la boîte de dialogue, confirmez que vous souhaitez supprimer l'accès à ce groupe.
Lorsque vous revenez à la page des détails du serveur, vous constatez que l'accès à ce groupe n'est plus répertorié.
## Connexion au serveur via SSH (Secure Shell)
Après avoir configuré votre serveur et vos utilisateurs, vous pouvez vous connecter au serveur via SSH et utiliser le nom d'utilisateur complet d'un utilisateur qui y a accès.
```
sftp user@active-directory-domain@vpc-endpoint
```
Par exemple : `transferuserexample@mycompany.com@vpce-0123456abcdef-789xyz.vpc-svc-987654zyxabc.us-east-1.vpce.amazonaws.com`.
Ce format cible la recherche de la fédération, limitant ainsi la recherche dans un Active Directory potentiellement volumineux.
**Note**
Vous pouvez spécifier le nom d'utilisateur simple. Toutefois, dans ce cas, le code Active Directory doit effectuer une recherche dans tous les annuaires de la fédération. Cela peut limiter la recherche et l'authentification peut échouer même si l'utilisateur doit y avoir accès.
Une fois authentifié, l'utilisateur se trouve dans le répertoire de base que vous avez spécifié lors de sa configuration.
## Connexion AWS Transfer Family à un Active Directory autogéré à l'aide de forêts et d'approbations
Directory Service dispose des options suivantes pour se connecter à un Active Directory autogéré :
+ La confiance forestière unidirectionnelle (sortante AWS Managed Microsoft AD et entrante pour Active Directory sur site) ne fonctionne que pour le domaine racine.
+ Pour les domaines enfants, vous pouvez utiliser l'une des options suivantes :
+ Utiliser une confiance bidirectionnelle entre Active AWS Managed Microsoft AD Directory et sur site
+ Utilisez une confiance externe unidirectionnelle pour chaque domaine enfant.
Lors de la connexion au serveur via un domaine sécurisé, l'utilisateur doit spécifier le domaine sécurisé, par exemple`transferuserexample@mycompany.com`.
# Utilisation du AWS Directory Service pour les services de domaine Entra ID
Pour les clients qui ont uniquement besoin d'un transfert SFTP et qui ne souhaitent pas gérer de domaine, il existe Simple Active Directory. Les clients qui souhaitent bénéficier des avantages d'Active Directory et de la haute disponibilité dans un service entièrement géré peuvent également utiliser AWS Managed Microsoft AD. Enfin, pour les clients qui souhaitent tirer parti de leur forêt Active Directory existante pour leur transfert SFTP, il existe le connecteur Active Directory.
Notez ce qui suit :
+ Pour tirer parti de votre forêt Active Directory existante pour vos besoins de transfert SFTP, vous pouvez utiliser le [connecteur Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html).
+ Si vous souhaitez bénéficier des avantages d'Active Directory et de la haute disponibilité dans un service entièrement géré, vous pouvez utiliser AWS Directory Service for Microsoft Active Directory. Pour en savoir plus, consultez [Utilisation de AWS Directory Service pour Microsoft Active Directory](directory-services-users.md).
Cette rubrique décrit comment utiliser un connecteur Active Directory et les [services de domaine Entra ID (anciennement Azure AD)](https://azure.microsoft.com/en-us/services/active-directory-ds/) pour authentifier les utilisateurs de SFTP Transfer avec l'identifiant Entra.
**Topics**
+ [Avant de commencer à utiliser AWS Directory Service pour les services de domaine Entra ID](#azure-prereq)
+ [Étape 1 : Ajouter les services de domaine Entra ID](#azure-add-adds)
+ [Étape 2 : Création d'un compte de service](#azure-create-service-acct)
+ [Étape 3 : Configuration de l' AWS annuaire à l'aide d'AD Connector](#azure-setup-directory)
+ [Étape 4 : Configuration AWS Transfer Family du serveur](#azure-setup-transfer-server)
+ [Étape 5 : Accorder l'accès aux groupes](#azure-grant-access)
+ [Étape 6 : Tester les utilisateurs](#azure-test)
## Avant de commencer à utiliser AWS Directory Service pour les services de domaine Entra ID
**Note**
AWS Transfer Family a une limite par défaut de 100 groupes Active Directory par serveur. Si votre cas d'utilisation nécessite plus de 100 groupes, envisagez d'utiliser une solution de fournisseur d'identité personnalisée, comme décrit dans [Simplifier l'authentification Active Directory avec un fournisseur d'identité personnalisé pour AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
Pour cela AWS, vous avez besoin des éléments suivants :
+ Un cloud privé virtuel (VPC) dans une AWS région où vous utilisez vos serveurs Transfer Family
+ Au moins deux sous-réseaux privés dans votre VPC
+ Le VPC doit disposer d'une connexion Internet
+ Une passerelle client et une passerelle privée virtuelle pour la connexion site-to-site VPN avec Microsoft Entra
Pour Microsoft Entra, vous avez besoin des éléments suivants :
+ Un identifiant Entra et un service de domaine Active Directory
+ Un groupe de ressources Entra
+ Un réseau virtuel Entra
+ Connectivité VPN entre votre Amazon VPC et votre groupe de ressources Entra
**Note**
Cela peut se faire par le biais de tunnels IPSEC natifs ou d'appareils VPN. Dans cette rubrique, nous utilisons des tunnels IPSEC entre une passerelle réseau virtuelle Entra et une passerelle réseau locale. Les tunnels doivent être configurés pour autoriser le trafic entre les points de terminaison de votre service de domaine Entra et les sous-réseaux qui hébergent votre AWS VPC.
+ Une passerelle client et une passerelle privée virtuelle pour la connexion site-to-site VPN avec Microsoft Entra
Le schéma suivant montre la configuration requise avant de commencer.
![\[Entra/Azure AD et schéma d'architecture. AWS Transfer Family Un AWS VPC se connectant à un réseau virtuel Entra via Internet, à l'aide d'un connecteur AWS Directory Service vers le service de domaine Entra.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-architecture.png)
## Étape 1 : Ajouter les services de domaine Entra ID
Entra ID ne prend pas en charge les instances de jointure de domaines par défaut. Pour effectuer des actions telles que l'adhésion à un domaine et pour utiliser des outils tels que la politique de groupe, les administrateurs doivent activer les services de domaine Entra ID. Si vous n'avez pas encore ajouté Entra DS, ou si votre implémentation existante n'est pas associée au domaine que vous souhaitez que votre serveur de transfert SFTP utilise, vous devez ajouter une nouvelle instance.
Pour plus d'informations sur l'activation des services de domaine Entra ID, voir [Tutoriel : Création et configuration d'un domaine géré par les services de domaine Microsoft Entra](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started) ID.
**Note**
Lorsque vous activez Entra DS, assurez-vous qu'il est configuré pour le groupe de ressources et le domaine Entra auxquels vous connectez votre serveur de transfert SFTP.
![\[Accédez à l'écran des services de domaine affichant le groupe de ressources bob.us en cours d'exécution.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-ad-add-instance.png)
## Étape 2 : Création d'un compte de service
Entra doit disposer d'un compte de service faisant partie d'un groupe d'administrateurs dans Entra DS. Ce compte est utilisé avec le connecteur AWS Active Directory. Assurez-vous que ce compte est synchronisé avec Entra DS.
![\[Accédez à l'écran affichant le profil d'un utilisateur.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-service-acct.png)
**Astuce**
L'authentification multifactorielle pour Entra ID n'est pas prise en charge pour les serveurs Transfer Family qui utilisent le protocole SFTP. Le serveur Transfer Family ne peut pas fournir le jeton MFA une fois qu'un utilisateur s'est authentifié auprès du protocole SFTP. Assurez-vous de désactiver le MFA avant de tenter de vous connecter.
![\[Entrez les détails de l'authentification multifactorielle, indiquant que le statut MFA est désactivé pour deux utilisateurs.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-ad-mfa-disable.png)
## Étape 3 : Configuration de l' AWS annuaire à l'aide d'AD Connector
Après avoir configuré Entra DS et créé un compte de service avec des tunnels VPN IPSEC entre votre AWS VPC et le réseau virtuel Entra, vous pouvez tester la connectivité en envoyant un ping à l'adresse IP DNS d'Entra DS depuis AWS n'importe quelle instance EC2.
Après avoir vérifié que la connexion est active, vous pouvez continuer ci-dessous.
**Pour configurer votre AWS annuaire à l'aide d'AD Connector**
1. Ouvrez la console [Directory Service](https://console.aws.amazon.com/directoryservicev2/) et sélectionnez **Directories**.
1. Sélectionnez **Configurer le répertoire**.
1. Pour le type de répertoire, choisissez **AD Connector**.
1. Sélectionnez une taille de répertoire, sélectionnez **Suivant**, puis sélectionnez votre VPC et vos sous-réseaux.
1. Sélectionnez **Suivant**, puis renseignez les champs comme suit :
+ **Nom DNS du répertoire** : entrez le nom de domaine que vous utilisez pour votre Entra DS.
+ **Adresses IP DNS** : entrez vos adresses IP Entra DS.
+ **Nom d'utilisateur et **mot de passe** du compte serveur** : entrez les détails du compte de service que vous avez créé à l'*étape 2 : créer un compte de service*.
1. Complétez les écrans pour créer le service d'annuaire.
Le statut du répertoire doit maintenant être **actif** et il est prêt à être utilisé avec un serveur de transfert SFTP.
![\[L'écran des services d'annuaire affiche un répertoire dont le statut est Actif, selon les besoins.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-connector-ready.png)
## Étape 4 : Configuration AWS Transfer Family du serveur
Créez un serveur Transfer Family avec le protocole SFTP et le type de fournisseur d'identité **AWS Directory Service**. Dans la liste déroulante **Répertoire**, sélectionnez le répertoire que vous avez ajouté à l'*étape 3 : Configuration du AWS répertoire à l'aide d'AD Connector*.
**Note**
Vous ne pouvez pas supprimer un répertoire Microsoft AD dans AWS Directory Service si vous l'avez utilisé sur un serveur Transfer Family. Vous devez d'abord supprimer le serveur, puis vous pouvez supprimer le répertoire.
## Étape 5 : Accorder l'accès aux groupes
Après avoir créé le serveur, vous devez choisir les groupes du répertoire qui doivent avoir accès au chargement et au téléchargement de fichiers via les protocoles activés à l'aide de AWS Transfer Family. Pour ce faire, créez un *accès*.
**Note**
Les utilisateurs doivent appartenir *directement* au groupe auquel vous accordez l'accès. Par exemple, supposons que Bob est un utilisateur et appartient au groupe A, et que le groupe A lui-même est inclus dans le groupe B.
Si vous accordez l'accès à GroupA, Bob est autorisé à y accéder.
Si vous accordez l'accès au groupe B (et non au groupe A), Bob n'y a pas accès.
Pour accorder l'accès, vous devez récupérer le SID du groupe.
Utilisez la PowerShell commande Windows suivante pour récupérer le SID d'un groupe, en le *YourGroupName* remplaçant par le nom du groupe.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
![\[Windows PowerShell affichant un SID d'objet en cours de récupération.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-grant-access.png)
**Accorder l'accès aux groupes**
1. Ouvrir [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Accédez à la page des détails de votre serveur et dans la section **Accès**, sélectionnez **Ajouter un accès**.
1. Entrez le SID que vous avez reçu à la sortie de la procédure précédente.
1. Pour **Access**, choisissez un Gestion des identités et des accès AWS rôle pour le groupe.
1. Dans la section **Stratégie**, choisissez une stratégie. La valeur par défaut est **Aucune**.
1. Pour le **répertoire personnel**, choisissez un compartiment Amazon S3 correspondant au répertoire personnel du groupe.
1. Choisissez **Ajouter** pour créer l'association.
Les informations provenant de votre serveur de transfert doivent ressembler à ce qui suit :
![\[Partie de l'écran des détails du serveur Transfer Family, présentant un exemple d'ID de répertoire pour le fournisseur d'identité.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-assoc-1.png)
![\[Partie de l'écran des détails du serveur Transfer Family, affichant l'ID externe de l'Active Directory dans la partie Accès de l'écran.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/azure-assoc-2.png)
## Étape 6 : Tester les utilisateurs
Vous pouvez tester ([Tester les utilisateurs](directory-services-users.md#directory-services-test-user)) si un utilisateur a accès au AWS Managed Microsoft AD répertoire de votre serveur. Un utilisateur doit appartenir exactement à un groupe (un ID externe) répertorié dans la section **Accès** de la page de **configuration du point de terminaison**. Si l'utilisateur ne fait partie d'aucun groupe, ou s'il fait partie de plusieurs groupes, il n'est pas autorisé à y accéder.