Utilisation de répertoires logiques pour simplifier vos structures de répertoires Transfer Family - AWS Transfer Family

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.

Utilisation de répertoires logiques pour simplifier vos structures de répertoires Transfer Family

Pour simplifier la structure des répertoires de votre AWS Transfer Family serveur, vous pouvez utiliser des répertoires logiques. Avec les répertoires logiques, vous pouvez créer une structure de répertoire virtuel qui utilise des noms faciles à utiliser par vos utilisateurs lorsqu'ils se connectent à votre compartiment Amazon S3 ou à votre système de fichiers Amazon EFS. Lorsque vous utilisez des répertoires logiques, vous pouvez éviter de divulguer les chemins de répertoire absolus, les noms des compartiments Amazon S3 et les noms des systèmes de fichiers EFS à vos utilisateurs finaux.

Note

Vous devez utiliser des politiques de session afin que vos utilisateurs finaux ne puissent effectuer que les opérations que vous les autorisez à effectuer.

Vous devez utiliser des répertoires logiques pour créer un répertoire virtuel convivial pour vos utilisateurs finaux et supprimer les noms de compartiments. Les mappages de répertoires logiques permettent uniquement aux utilisateurs d'accéder à leurs chemins logiques et sous-répertoires désignés, et interdisent les chemins relatifs qui traversent les racines logiques.

Transfer Family valide tous les chemins susceptibles d'inclure des éléments relatifs et bloque activement la résolution de ces chemins avant que nous ne les transmettions à Amazon S3 ; cela empêche vos utilisateurs d'aller au-delà de leurs mappages logiques.

Même si Transfer Family empêche vos utilisateurs finaux d'accéder à des répertoires situés en dehors de leur répertoire logique, nous vous recommandons également d'utiliser des rôles ou des politiques de session uniques pour appliquer le moindre privilège au niveau du stockage.

Vous pouvez utiliser des répertoires logiques pour placer le répertoire racine de l'utilisateur à l'emplacement souhaité dans votre hiérarchie de stockage, en effectuant ce que l'on appelle une chroot opération. Dans ce mode, les utilisateurs ne peuvent pas accéder à un répertoire en dehors du répertoire de base ou du répertoire racine que vous avez configuré pour eux.

Par exemple, bien qu'un utilisateur Amazon S3 ait été limité à l'accès uniquement/mybucket/home/${transfer:UserName}, certains clients autorisent les utilisateurs à parcourir un dossier vers /mybucket/home le haut. Dans ce cas, l'utilisateur revient sur le répertoire de base prévu uniquement après s'être déconnecté et reconnecté au serveur Transfer Family. L'exécution d'une chroot opération peut empêcher cette situation de se produire.

Vous pouvez créer votre propre structure de répertoire à partir de buckets et de préfixes. Cette fonctionnalité est utile si votre flux de travail attend une structure de répertoire spécifique que vous ne pouvez pas répliquer via des préfixes de compartiment. Vous pouvez également créer un lien vers plusieurs emplacements non contigus dans Amazon S3, comme pour créer un lien symbolique dans un système de fichiers Linux où le chemin de votre répertoire fait référence à un emplacement différent dans le système de fichiers.

Mappages de fichiers de répertoires logiques

Le type de HomeDirectoryMapEntry données inclut désormais un Type paramètre. Avant que ce paramètre n'existe, vous auriez pu créer un mappage de répertoire logique dont la cible était un fichier. Si vous avez déjà créé l'un de ces types de mappages de répertoires logiques, vous devez définir explicitement le Type toFILE, sinon ces mappages ne fonctionneront plus correctement à l'avenir.

Pour ce faire, vous pouvez appeler l'UpdateUserAPI et définir le Type to FILE pour le mappage existant.

Règles d'utilisation des répertoires logiques

Avant de créer vos mappages de répertoires logiques, vous devez comprendre les règles suivantes :

  • Dans Entry ce cas"/", vous ne pouvez avoir qu'un seul mappage car les chemins qui se chevauchent ne sont pas autorisés.

  • Les répertoires logiques prennent en charge des mappages allant jusqu'à 2,1 Mo (pour les utilisateurs gérés par des services, cette limite est de 2 000 entrées). C'est-à-dire que la structure de données contenant les mappages a une taille maximale de 2,1 Mo. Si vous avez un grand nombre de mappages, vous pouvez calculer la taille de vos mappages comme suit :

    1. Rédigez un mappage type dans le format{"Entry":"/entry-path","Target":"/target-path"}, où entry-path et target-path sont les valeurs réelles que vous allez utiliser.

    2. Comptez les caractères de cette chaîne, puis ajoutez-en un (1).

    3. Multipliez ce nombre par le nombre approximatif de mappages dont vous disposez pour votre serveur.

    Si le nombre que vous avez estimé à l'étape 3 est inférieur à 2,1 Mo, vos mappages se situent dans la limite acceptable.

  • Les cibles peuvent utiliser la ${transfer:UserName} variable si le chemin du bucket ou du système de fichiers a été paramétré en fonction du nom d'utilisateur.

  • Les cibles peuvent être des chemins situés dans différents compartiments ou systèmes de fichiers, mais vous devez vous assurer que le rôle mappé AWS Identity and Access Management (IAM) (Roleparamètre de la réponse) donne accès à ces compartiments ou systèmes de fichiers.

  • Ne spécifiez pas le HomeDirectory paramètre, car cette valeur est implicite par les Entry Target paires lorsque vous utilisez la LOGICAL valeur du HomeDirectoryType paramètre.

  • Les cibles doivent commencer par une barre oblique (/), mais n'utilisez pas de barre oblique (/) lorsque vous spécifiez le. Target Par exemple, /DOC-EXAMPLE-BUCKET/images c'est acceptable, mais /DOC-EXAMPLE-BUCKET/images/ ne DOC-EXAMPLE-BUCKET/images l'est pas.

  • Amazon S3 est un magasin d'objets, ce qui signifie que les dossiers sont un concept virtuel et qu'il n'existe aucune hiérarchie de répertoires réelle. Si votre application émet une stat opération depuis un client, tout est classé dans un fichier lorsque vous utilisez Amazon S3 pour le stockage. Ce comportement est décrit dans la section Organisation des objets dans la console Amazon S3 à l'aide de dossiers du guide de l'utilisateur d'Amazon Simple Storage Service. Si votre application nécessite d'indiquer stat avec précision s'il s'agit d'un fichier ou d'un dossier, vous pouvez utiliser Amazon Elastic File System (Amazon EFS) comme option de stockage pour vos serveurs Transfer Family.

  • 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 dansHomeDirectoryDetails.

Important

À moins que vous ne choisissiez d'optimiser les performances de vos annuaires Amazon S3 (lorsque vous créez ou mettez à jour un serveur), le répertoire racine doit exister au démarrage. Pour Amazon S3, cela signifie que vous devez déjà avoir créé un objet de zéro octet se terminant par une barre oblique (/) pour créer le dossier racine. Éviter ce problème est une raison pour envisager d'optimiser les performances d'Amazon S3.

Implémentation de répertoires logiques et chroot

Pour utiliser les répertoires et les chroot fonctionnalités logiques, vous devez effectuer les opérations suivantes :

Activez les répertoires logiques pour chaque utilisateur. Pour ce faire, définissez le HomeDirectoryType paramètre sur LOGICAL lorsque vous créez ou mettez à jour votre utilisateur.

"HomeDirectoryType": "LOGICAL"

chroot

Pour chroot créer une structure de répertoire composée d'un répertoire unique Entry et d'un Target appariement pour chaque utilisateur. Le dossier racine est le Entry point et l'Targetemplacement de votre bucket ou de votre système de fichiers vers lequel mapper.

Example for Amazon S3
[{"Entry": "/", "Target": "/mybucket/jane"}]
Example for Amazon EFS
[{"Entry": "/", "Target": "/fs-faa1a123/jane"}]

Vous pouvez utiliser un chemin absolu comme dans l'exemple précédent, ou vous pouvez utiliser une substitution dynamique pour le nom d'utilisateur par${transfer:UserName}, comme dans l'exemple suivant.

[{"Entry": "/", "Target": "/mybucket/${transfer:UserName}"}]

Dans l'exemple précédent, l'utilisateur est verrouillé dans son répertoire racine et ne peut pas monter plus haut dans la hiérarchie.

Structure du répertoire virtuel

Pour une structure de répertoire virtuel, vous pouvez créer plusieurs Entry Target paires, avec des cibles n'importe où dans vos compartiments S3 ou systèmes de fichiers EFS, y compris dans plusieurs compartiments ou systèmes de fichiers, à condition que le mappage des rôles IAM de l'utilisateur soit autorisé à y accéder.

Dans l'exemple de structure virtuelle suivant, lorsque l'utilisateur se connecte à AWS SFTP, il se trouve dans le répertoire racine avec les sous-répertoires/pics, /doc/reporting, et. /anotherpath/subpath/financials

Note

À moins que vous ne choisissiez d'optimiser les performances de vos annuaires Amazon S3 (lorsque vous créez ou mettez à jour un serveur), l'utilisateur ou un administrateur doit créer les annuaires s'ils n'existent pas déjà. Éviter ce problème est une raison pour envisager d'optimiser les performances d'Amazon S3.

Pour Amazon EFS, vous avez toujours besoin de l'administrateur pour créer les mappages logiques ou le / répertoire.

[ {"Entry": "/pics", "Target": "/bucket1/pics"}, {"Entry": "/doc", "Target": "/bucket1/anotherpath/docs"}, {"Entry": "/reporting", "Target": "/reportingbucket/Q1"}, {"Entry": "/anotherpath/subpath/financials", "Target": "/reportingbucket/financials"}]

Note

Vous ne pouvez télécharger des fichiers que dans les dossiers spécifiques que vous mappez. Cela signifie que dans l'exemple précédent, vous ne pouvez pas télécharger vers /anotherpath des anotherpath/subpath répertoires ; uniquementanotherpath/subpath/financials. Vous ne pouvez pas non plus mapper directement ces tracés, car les tracés qui se chevauchent ne sont pas autorisés.

Supposons, par exemple, que vous créez les mappages suivants :

{ "Entry": "/pics", "Target": "/mybucket/pics" }, { "Entry": "/doc", "Target": "/mybucket/mydocs" }, { "Entry": "/temp", "Target": "/mybucket" }

Vous ne pouvez télécharger des fichiers que dans ces compartiments. Lorsque vous vous connectez pour la première foissftp, vous êtes déposé dans le répertoire racine,/. Si vous essayez de télécharger un fichier dans ce répertoire, le téléchargement échoue. Les commandes suivantes présentent un exemple de séquence :

sftp> pwd Remote working directory: / sftp> put file Uploading file to /file remote open("/file"): No such file or directory

Pour télécharger vers n'importe quel fichierdirectory/sub-directory, vous devez mapper explicitement le chemin vers lesub-directory.

Pour plus d'informations sur la configuration des répertoires logiques et chroot pour vos utilisateurs, y compris un AWS CloudFormation modèle que vous pouvez télécharger et utiliser, consultez Simplifier votre structure AWS SFTP avec un chroot et des répertoires logiques dans le blog AWS de stockage.

Exemple de configuration de répertoires logiques

Dans cet exemple, nous créons un utilisateur et lui attribuons deux répertoires logiques. La commande suivante crée un nouvel utilisateur (pour un serveur Transfer Family existant) avec des répertoires logiques pics etdoc.

aws transfer create-user --user-name marymajor-logical --server-id s-11112222333344445 --role arn:aws:iam::1234abcd5678:role/marymajor-role --home-directory-type LOGICAL \ --home-directory-mappings "[{\"Entry\":\"/pics\", \"Target\":\"/DOC-EXAMPLE-BUCKET1/pics\"}, {\"Entry\":\"/doc\", \"Target\":\"/DOC-EXAMPLE-BUCKET2/test/mydocs\"}]" \ --ssh-public-key-body file://~/.ssh/id_rsa.pub

S'il s'marymajoragit d'un utilisateur existant et que son répertoire personnel est de typePATH, vous pouvez le remplacer LOGICAL par une commande similaire à la précédente.

aws transfer update-user --user-name marymajor-logical \ --server-id s-11112222333344445 --role arn:aws:iam::1234abcd5678:role/marymajor-role \ --home-directory-type LOGICAL --home-directory-mappings "[{\"Entry\":\"/pics\", \"Target\":\"/DOC-EXAMPLE-BUCKET1/pics\"}, \ {\"Entry\":\"/doc\", \"Target\":\"/DOC-EXAMPLE-BUCKET2/test/mydocs\"}]"

Notez ce qui suit :

  • Si /DOC-EXAMPLE-BUCKET1/pics les répertoires /DOC-EXAMPLE-BUCKET2/test/mydocs n'existent pas déjà, l'utilisateur (ou un administrateur) doit les créer.

  • Lorsqu'elle marymajor se connecte au serveur et exécute la ls -l commande, Mary voit ce qui suit :

    drwxr--r-- 1 - - 0 Mar 17 15:42 doc drwxr--r-- 1 - - 0 Mar 17 16:04 pics
  • marymajorImpossible de créer des fichiers ou des répertoires à ce niveau. Cependant, dans pics etdoc, elle peut ajouter des sous-répertoires.

  • Les fichiers que Mary ajoute pics et doc sont ajoutés aux chemins Amazon S3 /DOC-EXAMPLE-BUCKET1/pics et /DOC-EXAMPLE-BUCKET2/test/mydocs respectivement.

  • Dans cet exemple, nous indiquons deux compartiments différents pour illustrer cette possibilité. Toutefois, vous pouvez utiliser le même compartiment pour plusieurs ou tous les répertoires logiques que vous spécifiez pour l'utilisateur.

Configuration de répertoires logiques pour Amazon EFS

Si votre serveur Transfer Family utilise Amazon EFS, le répertoire personnel de l'utilisateur doit être créé avec un accès en lecture et en écriture pour que l'utilisateur puisse travailler dans son répertoire de base logique. L'utilisateur ne peut pas créer ce répertoire lui-même, car il n'aurait pas les autorisations nécessaires pour mkdir accéder à son répertoire de base logique.

Si le répertoire personnel de l'utilisateur n'existe pas et que celui-ci exécute une ls commande, le système répond comme suit :

sftp> ls remote readdir ("/"): No such file or directory

Un utilisateur disposant d'un accès administratif au répertoire parent doit créer le répertoire de base logique de l'utilisateur.

AWS Lambda Réponse personnalisée

Vous pouvez utiliser des répertoires logiques dotés d'une fonction Lambda qui se connecte à votre fournisseur d'identité personnalisé. Pour ce faire, dans votre fonction Lambda, vous spécifiez les Target valeurs HomeDirectoryType asLOGICAL, add Entry et pour le HomeDirectoryDetails paramètre. Par exemple :

HomeDirectoryType: "LOGICAL" HomeDirectoryDetails: "[{\"Entry\": \"/\", \"Target\": \"/DOC-EXAMPLE-BUCKET/theRealFolder"}]"

Le code suivant est un exemple de réponse réussie à un appel d'authentification Lambda personnalisé.

aws transfer test-identity-provider --server-id s-1234567890abcdef0 --user-name myuser { "Url": "https://a1b2c3d4e5.execute-api.us-east-2.amazonaws.com/prod/servers/s-1234567890abcdef0/users/myuser/config", "Message": "", "Response": "{\"Role\": \"arn:aws:iam::123456789012:role/bob-usa-role\",\"HomeDirectoryType\": \"LOGICAL\",\"HomeDirectoryDetails\": \"[{\\\"Entry\\\":\\\"/myhome\\\",\\\"Target\\\":\\\"/DOC-EXAMPLE-BUCKET/theRealFolder\\\"}]\",\"PublicKeys\": \"[ssh-rsa myrsapubkey]\"}", "StatusCode": 200 }
Note

La "Url": ligne est renvoyée uniquement si vous utilisez une méthode API Gateway comme fournisseur d'identité personnalisé.