翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
論理ディレクトリを使用して Transfer Family ディレクトリ構造を簡素化する
AWS Transfer Family サーバーディレクトリ構造を簡素化するには、論理ディレクトリを使用できます。論理ディレクトリを使用すると、ユーザーが Amazon S3 バケットまたは Amazon EFS ファイルシステムに接続するときにナビゲートするわかりやすい名前を使用する仮想ディレクトリ構造を構築できます。論理ディレクトリを使用する場合、絶対ディレクトリパス、Amazon S3 バケット名、およびEFSファイルシステム名をエンドユーザーに開示することは避けることができます。
注記
セッションポリシーやその他の内部要件の使用によって異なりますが、通常、ユーザーが意図したファイルのみにアクセスできるようにするために、セッションポリシーと論理ディレクトリの両方は必要ありません。論理ディレクトリを設定する場合は、セッションポリシーも作成しないでください。両方があると、アクセス許可が拒否されるエラーが発生する可能性があります。
論理ディレクトリを使用すると、chroot オペレーションと呼ばれるものを実行することで、ストレージ階層内の目的の場所にユーザーのルートディレクトリを設定できます。このモードでは、ユーザーが構成したホームディレクトリまたはルートディレクトリの外部にあるディレクトリには移動できません。
たとえば、Amazon S3 ユーザーはアクセス専用 /
にスコープダウンされていますが、一部のクライアントでは、ユーザーがフォルダを mybucket
/home
/${transfer:UserName
}/
にトラバースアップできます。この場合、ユーザーは、Transfer Family サーバーからログアウトして再びログインした後でのみ、本来のホームディレクトリに戻ります。chroot オペレーションを実行すると、この状況が発生するのを防止できます。mybucket
/home
バケットとプレフィックスで独自のディレクトリ構造を作成できます。この機能は、バケットプレフィクスを介してレプリケートできない特定のディレクトリ構造を想定したワークフローがある場合に便利です。また、Amazon S3 内の複数の非連続な場所にリンクすることもでき、これはディレクトリパスがファイルシステム内の別の場所を参照する Linux ファイルシステム内にシンボリックリンクを作成するのと似ています。
論理ディレクトリFILEマッピング
HomeDirectoryMapEntry
データ型に Type
パラメータが含まれるようになりました。このパラメータが存在する前に、ターゲットが ファイルである論理ディレクトリマッピングを作成できたはずです。以前にこれらの種類の論理ディレクトリマッピングを作成した場合は、明示的に Type
を に設定する必要があります。設定しないとFILE
、これらのマッピングは今後正しく機能しません。
これを行う 1 つの方法は、 UpdateUser
を呼び出しAPI、既存のマッピングFILE
の Type
を に設定することです。
論理ディレクトリを使用する際のルール
論理ディレクトリマッピングを構築する前に、以下のルールを理解する必要があります。
-
Entry
が"/"
の場合、重複パスは許可されないので、設定できるマッピングは 1 つのみです。 -
論理ディレクトリは、最大 2.1 MB のマッピングをサポートします (サービスマネージドユーザーの場合、この制限は 2,000 エントリです)。つまり、マッピングを含むデータ構造の最大サイズは 2.1 MB です。マッピングが多い場合は、次のようにマッピングのサイズを計算できます。
-
一般的なマッピングを 形式で書き出します。ここで
{"Entry":"/
、entry-path
","Target":"/target-path
"}
とentry-path
は使用する実際の値です。target-path
-
その文字列の文字をカウントし、1 (1) を追加します。
-
その数に、サーバー用に持っているマッピングのおおよその数を掛けます。
ステップ 3 で推定した数が 2.1 MB 未満の場合、マッピングは許容制限内です。
-
-
バケットまたはファイルシステムのパスがユーザー名に基づいてパラメータ化されている場合、ターゲットは
${transfer:UserName}
変数を使用できます。 -
ターゲットは異なるバケットまたはファイルシステムのパスにすることができますが、マッピングされた AWS Identity and Access Management (IAM) ロール (レスポンスの
Role
パラメータ) がこれらのバケットまたはファイルシステムへのアクセスを提供することを確認する必要があります。 -
HomeDirectory
パラメータの値を使用している場合、この値はEntry
Target
ペアによって暗黙的に暗示されるため、LOGICAL
HomeDirectoryType
パラメータを指定しないでください。 -
ターゲットはスラッシュ (
/
) 文字で始まる必要がありますが、 を指定するときは、末尾のスラッシュ (/
) を使用しないでくださいTarget
。例えば、/
は許容されますが、DOC-EXAMPLE-BUCKET
/images
とDOC-EXAMPLE-BUCKET
/images/
は許容されません。DOC-EXAMPLE-BUCKET
/images/ -
Amazon S3 はオブジェクトストアです。つまり、フォルダは仮想概念であり、実際のディレクトリ階層はありません。アプリケーションがクライアントから
stat
オペレーションを発行した場合、ストレージに Amazon S3 を使用している場合、すべてがファイルとして分類されます。この動作については、Amazon Simple Storage Service ユーザーガイドの「 フォルダを使用した Amazon S3 コンソールのオブジェクトの整理」で説明されています。 アプリケーションで がファイルかフォルダかstat
を正確に表示する必要がある場合は、Transfer Family サーバーのストレージオプションとして Amazon Elastic File System (Amazon EFS) を使用できます。 -
ユーザーに論理ディレクトリ値を指定する場合、使用するパラメータはユーザーのタイプによって異なります。
-
サービス管理型ユーザーの場合、論理ディレクトリの値を
HomeDirectoryMappings
に指定してください。 -
カスタム ID プロバイダーユーザーの場合は、 に論理ディレクトリ値を指定します
HomeDirectoryDetails
。
-
重要
Amazon S3 ディレクトリのパフォーマンスを最適化することを選択しない限り (サーバーを作成または更新するとき)、ルートディレクトリは起動時に存在する必要があります。Amazon S3 の場合、ルートフォルダを作成するには、スラッシュ (/
) で終わるゼロバイトオブジェクトを既に作成している必要があります。この問題を回避することは、Amazon S3 のパフォーマンスの最適化を検討する理由です。
論理ディレクトリと の実装 chroot
論理ディレクトリと chroot 機能を使用するには、以下のことをする必要があります。
ユーザーごとの論理ディレクトリをオンにします。そのためには、ユーザーを作成または更新するときに HomeDirectoryType
パラメータを LOGICAL
に設定します。
"HomeDirectoryType": "LOGICAL"
chroot
chroot の場合、ユーザーごとに単一の Entry
と Target
のペア構成されるディレクトリ構造を作成します。ルートフォルダは Entry
ポイントであり、Target
はマップ先になるバケットまたはファイルシステム内の場所です。
前の例のように絶対パスを使うこともできるし、次の例のようにユーザー名を ${transfer:UserName}
でダイナミックに置換できます。
[{"Entry": "/", "Target": "/mybucket/${transfer:UserName}"}]
前の例では、ユーザーはルートディレクトリにロックされ、階層の上位には移動できません。
仮想ディレクトリ構造
仮想ディレクトリ構造では、ユーザーのIAMロールマッピングにそれらにアクセスするアクセス許可がある限り、複数のバケットまたはEFSファイルシステムを含む S3 バケットまたはファイルシステムの任意の場所にターゲットを持つ複数のEntry
Target
ペアリングを作成できます。
次の仮想構造の例では、ユーザーが にログインすると AWS SFTP、 /pics
、、/doc
、 /reporting
のサブディレクトリを持つルートディレクトリにあります/anotherpath/subpath/financials
。
注記
Amazon S3 ディレクトリのパフォーマンスを最適化することを選択しない限り (サーバーを作成または更新するとき)、ユーザーまたは管理者がディレクトリが存在しない場合は作成する必要があります。この問題を回避することは、Amazon S3 のパフォーマンスの最適化を検討する理由です。
Amazon の場合EFS、管理者は論理マッピングまたは /
ディレクトリを作成する必要があります。
[ {"Entry": "/pics", "Target": "/bucket1/pics"}, {"Entry": "/doc", "Target": "/bucket1/anotherpath/docs"}, {"Entry": "/reporting", "Target": "/reportingbucket/Q1"}, {"Entry": "/anotherpath/subpath/financials", "Target": "/reportingbucket/financials"}]
注記
ファイルは、マップした特定のフォルダにのみアップロードできます。つまり、前の例では、/anotherpath
または anotherpath/subpath
ディレクトリにはアップロードできず、anotherpath/subpath/financials
のみが可能です。また、重複するパスは許可されないため、これらのパスに直接マップすることはできません。
たとえば、次のマッピングを作成するとします。
{ "Entry": "/pics", "Target": "/mybucket/pics" }, { "Entry": "/doc", "Target": "/mybucket/mydocs" }, { "Entry": "/temp", "Target": "/mybucket" }
ファイルは、それらのバケットのみにアップロードできます。sftp
を通して初めて接続すると、ルートディレクトリ (/
) の階層まで落ちます。そのディレクトリにファイルをアップロードしようとすると、アップロードは失敗します。次のコマンドは、シーケンスの例を示しています。
sftp> pwd Remote working directory: / sftp> put file Uploading file to /file remote open("/file"): No such file or directory
任意の directory/sub-directory
にアップロードするには、パスを sub-directory
に明示的にマップする必要があります。
ダウンロードして使用できる AWS CloudFormation テンプレートなど、論理ディレクトリと ユーザーchrootの設定の詳細については、 AWS ストレージブログの「chroot と論理ディレクトリで構造を簡素化する AWS SFTP
論理ディレクトリの構成例
この例では、ユーザーを作成し、2 つの論理ディレクトリを割り当てます。次のコマンドは、論理ディレクトリpics
とdoc
を使用して新しいユーザー (既存のTTransfer Family ilyサーバー用) を作成します。
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
marymajor
が既存のユーザーで、ホームディレクトリのタイプがPATH
の場合、前のユーザーと同様のコマンドを使ってこれをLOGICAL
に変更できます。
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\"}]"
次の点に注意してください。
-
ディレクトリ
/
とDOC-EXAMPLE-BUCKET1
/pics/
がまだ存在しない場合は、ユーザ (または管理者) がディレクトリを作成する必要があります。DOC-EXAMPLE-BUCKET2
/test/mydocs -
marymajor
をサーバーに接続してls -l
コマンドを実行すると、次のように表示されます。drwxr--r-- 1 - - 0 Mar 17 15:42 doc drwxr--r-- 1 - - 0 Mar 17 16:04 pics
-
marymajor
はこのレベルではファイルやディレクトリは作成できません。ただし、pics
およびdoc
内には、サブディレクトリを追加できます。 -
彼女が
pics
とdoc
に追加したファイルと、それぞれAmazon S3 パス/
とDOC-EXAMPLE-BUCKET1
/pics/
にそれぞれ追加されます。DOC-EXAMPLE-BUCKET2
/test/mydocs -
この例では、その可能性を説明するために 2 つの異なるバケットを指定しています。ただし、ユーザーに指定した複数またはすべての論理ディレクトリに同じバケットを使用できます。
Amazon の論理ディレクトリを設定する EFS
Transfer Family サーバーが Amazon を使用している場合EFS、ユーザーが論理ホームディレクトリで作業する前に、ユーザーのホームディレクトリを読み取りおよび書き込みアクセスで作成する必要があります。ユーザーは自分の論理ホームディレクトリに対する mkdir
の権限がないため、このディレクトリを自分で作成することはできません。
ユーザーのホームディレクトリが存在せず、ユーザーが ls
コマンドを実行すると、システムは次のように応答します。
sftp> ls remote readdir ("/"): No such file or directory
親ディレクトリへの管理アクセス権を持つユーザーは、ユーザーの論理ホームディレクトリを作成する必要があります。
カスタム AWS Lambda レスポンス
論理ディレクトリは、カスタム ID プロバイダーに接続する Lambda 関数で使用できます。そのためには、Lambda 関数でHomeDirectoryType
をLOGICAL
として指定し、HomeDirectoryDetails
パラメータにEntry
とTarget
の値を追加します。例:
HomeDirectoryType: "LOGICAL" HomeDirectoryDetails: "[{\"Entry\": \"/\", \"Target\": \"/
DOC-EXAMPLE-BUCKET
/theRealFolder"}]"
以下のコードは、カスタム Lambda 認証コールからの成功レスポンスの例です。
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 }
注記
"Url":
行は、カスタム ID プロバイダーとして API Gateway メソッドを使用している場合のみ返されます。