Chroot と論理ディレクトリを使用して AWS SFTP 構造を簡素化する

最後のブログ記事で、AWS Transfer for SFTP (AWS SFTP) の ID プロバイダーとして AWS Secrets Manager を簡単にセットアップし、パスワード認証を有効にする方法を示しました。この記事では、論理ディレクトリと呼ばれる新機能を使用して、ユーザーに仮想ネームスペースの設定情報を渡すために、その ID プロバイダーのセットアップを活用する方法を説明します。

バケットの可視性

現在のセットアップを見てみましょう。ユーザーが AWS SFTP エンドポイントにログインすると、HomeDirectory にドロップされます。たとえば、ユーザー「Jess」の場合、これは/mybucket/home/jess になるでしょう。

ただし、SFTP クライアントコマンドを使用すると、Jess は Amazon S3 階層内の現在のパスを確認し、cd.. を使用してそのフォルダ構造をナビゲートできます。

ユーザーの Jess がスコープダウンして /mybucket/home/${transfer:UserName} にのみアクセスする場合でも、一部のクライアントはユーザーがフォルダを/mybucket/home へトラバースすることを許可しています。ログアウトして再度ログインするだけで、HomeDirectory に戻ります。

例:

これを防ぐための新しい方法を見てみましょう。

論理ディレクトリ

論理ディレクトリを使用すると、ユーザーがナビゲートできる仮想ディレクトリ構造を構築できます。エンドユーザーに優れたエクスペリエンスを提供する一方で、エンドユーザーに S3 バケットの絶対パス (バケット名を含む) を公開しないという柔軟性が得られます。

これが適用されるシナリオがいくつかあります。ユーザーのルートディレクトリを Amazon S3 バケット階層内の目的の場所にリセットすることもできます。これは「chroot」操作として知られています。このモードでは、ユーザーが cd.. をどれだけ難しくしようとしても、ルートディレクトリは設定したときのままになります。

2 番目のシナリオでは、バケットとプレフィックスにまたがる独自のディレクトリ構造を作成できます。これは、バケットプレフィックスを使用して複製できない特定のディレクトリ構造を想定しているワークフローがある場合、または S3 内の複数の不連続な場所にリンクする場合に役立ちます。これは、ディレクトリパスがファイルシステムの別の場所を参照する Linux ファイルシステムでシンボリックリンクを作成するときのようなものと考えることができます。

これらのモードは両方とも、Entry と Target の組み合わせのリストを提供することで機能します。

最初に行う必要があるのは、ユーザーの機能を有効にすることです。これを行うには、ユーザー設定の一部として新しいパラメータを返す必要があります。

キー:	`HomeDirectoryType`
値:	`LOGICAL`

Chroot

次に、ディレクトリ構造を構築する必要があります。chroot の場合、次のように、単一のペアリングがあり、ルートフォルダは Entry ポイントであり、バケット構造内でマッピングする場所は Target です

[{"Entry": "/", "Target": "/mybucket/jess"}]

これは、上に示すように絶対パスにすることも、${Transfer:UserName} でユーザー名を動的に置換することもできます。

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

これは、ディレクトリを移動しようとしたときにコマンドラインに表示される結果です。ルートフォルダにロックされたため、階層を上に移動できません。

SFTP-Logical-Directories-Command-Line-2

仮想構造

完全な仮想ディレクトリ構造を作成する場合は、ユーザーの S3 ロールマッピングにアクセスする権限がある限り、S3 バケット内の任意の場所 (バケット全体を含む) をターゲットにして複数のペアリングを提供できます。

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

この仮想構造の例を使用して、このユーザーの AWS SFTP にログインすると、/pics、/doc、/reporting、および /anotherpath/subpath/financials のサブディレクトリがあるルートディレクトリに移動します。

例:

SFTP-Logical-Directories-Command-Line-3

ご自身で試してみてください

では、試してみましょう。

この AWS CloudFormation テンプレートをダウンロードしてデプロイします。

このテンプレートでデプロイされるものの詳細については、最新のブログ記事を参照し、指示に従って AWS Secrets Manager でユーザーをセットアップしてください。ただし、HomeDirectory パラメータは含めないでください。

テンプレートで AWS SFTP サーバーをデプロイすることを選択した場合、指示のこの部分もスキップできます。

ここで、次のように、Secrets Manager でユーザーに新しいキーと値のペアを追加する必要があります。

キー:	`HomeDirectoryDetails`
値:	`Your Entry/Target Pairings`

以下に、より具体的な例を示します。次のように、バケット構造に一致するようにこれを変更する必要があります。

キー:	`HomeDirectoryDetails`
値:	`[{"Entry": "/pics", "Target": "/bucket1/pics"}, {"Entry": "/reporting", "Target": "/bucket2/path/reporting"}]`

HomeDirectoryType = LOGICAL 設定について触れたことを覚えていますか? これは、ユーザー設定で HomeDirectoryDetails キーを見つけると、AWS Lambda 統合によって応答ヘッダーに自動的に含まれます。

この設定はログインするすべてのユーザーに動的に適用されるため、Lambda で、またはディレクトリを操作して、オンデマンドでこのマッピングを更新することにより、クリエイティブになれます。たとえば、今月のプレフィックスへの動的なマッピングまたはレポートはどうでしょうか?

マッピングを作成する前に、次のように理解すべきルールがいくつかあります。

エントリが「/」では、重複するパスは許可されないため、マッピングは 1 つしか持てません。
ターゲットは ${Transfer:UserName 変数を使用できます (バケットパスがユーザー名に基づいてパラメータ化されている場合)。
ターゲットは異なるバケット内のパスにすることができますが、マッピングされた IAM ロール (応答中のロールパラメータ) がそのバケットへのアクセスを提供することを確認する必要があります。
LOGICAL ホームディレクトリタイプのオプションを使用する場合、この値はエントリターゲットペアによって暗示されるため、HomeDirectory パラメータを指定する必要はなくなりました。

これが、「chroot」と「symlink」のような機能を提供する新しい論理ディレクトリ機能です! これにより、複雑なスコープダウンポリシーを構築し、既存のクライアント側スクリプトを変更する必要性を軽減します。また S3バケット階層がエンドユーザーに表示されないようにすることで、必要なプライバシーを確保できます。これは、より多くの SFTP ワークフローをシームレスに AWS に移行できることを意味します。

これを試す際にデプロイした可能性のあるリソースをクリーンアップすることを忘れないでください。

論理ディレクトリの詳細については、最新の AWS ストレージのブログ「AWS SFTP 論理ディレクトリを使用して、シンプルデータ配信サービスを構築する」を参照してください。

Amazon Web Services ブログ