翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # サーバーエンドポイントのユーザーの管理 以下のセクションでは、 AWS Transfer Family AWS Directory Service for Microsoft Active Directory またはカスタム ID プロバイダーを使用してユーザーを追加する方法について説明します。 各ユーザーのプロパティの一部として、そのユーザーの Secure Shell (SSH) パブリックキーも保存します。キーベースの認証にはこれが必要です。プライベートキーは、ユーザーのコンピュータにローカルに保存されます。ユーザーがクライアントを使用してサーバーに認証要求を送信すると、サーバーはまず、ユーザーが関連付けられた SSH 秘密キーにアクセスできることを確認します。その後、サーバーはユーザーを正常に認証します。 **注記** 複数の SSH キーを持つユーザーの自動デプロイと管理については、「」を参照してください[Transfer Family Terraform モジュール](terraform.md)。 さらに、ユーザーのホームディレクトリ、またはランディングディレクトリを指定して、ユーザーに AWS Identity and Access Management (IAM) ロールを割り当てます。必要に応じて、セッションポリシーを提供してユーザーアクセスを Amazon S3 バケットのホームディレクトリのみに限定できます。 **重要** AWS Transfer Family は、SFTP サーバーへの認証から 1 ～ 2 文字の長さのユーザー名をブロックします。さらに、`root` ユーザー名もブロックされます。 これは、パスワードスキャナによる悪意のあるログイン試行の大量発生が原因です。 ## Amazon EFS と Amazon S3 の比較 各ストレージオプションの特性: + アクセスを制限するために、Amazon S3 はセッションポリシーをサポートし、Amazon EFS は POSIX ユーザー、グループ、およびセカンダリグループ ID をサポートします。 + いずれもパブリックキー/プライベートキーをサポートする + いずれもホームディレクトリをサポートする + いずれも論理ディレクトリをサポートする **注記** Amazon S3 では、論理ディレクトリのサポートの大部分は API/CLI 経由です。コンソールの [**Restricted**] (制限) チェックボックスを使用すると、ユーザーをホームディレクトリにロックダウンできますが、仮想ディレクトリ構造は指定できません。 ## 論理ディレクトリ ユーザーに対して論理ディレクトリ値を指定する場合、使用するパラメータはユーザーのタイプに依存します。 + サービス管理型ユーザーの場合、論理ディレクトリの値を `HomeDirectoryMappings` に指定してください。 + カスタム ID プロバイダーユーザーの場合は、 で論理ディレクトリ値を指定します`HomeDirectoryDetails`。 AWS Transfer Family は、LOGICAL HomeDirectory HomeDirectoryType 値の指定をサポートしています。これは、レスポンスで HomeDirectoryDetails が提供されているサービスマネージドユーザー、Active Directory アクセス、カスタム ID プロバイダーの実装に適用されます。 **重要** LOGICAL HomeDirectory HomeDirectoryType を指定する場合、値は論理ディレクトリマッピングのいずれかにマッピングする必要があります。サービスは、ユーザーの作成時と更新時の両方でこれを検証し、機能しない設定を防止します。 ### デフォルトの 動作 デフォルトでは、指定しない場合、HomeDirectory は LOGICAL モードの「/」に設定されます。この動作は変更されず、既存のユーザー定義と互換性があります。 + HomeDirectory はターゲットではなく*エントリ*にマッピングしてください**。詳細については、[論理ディレクトリを使用する際のルール](logical-dir-mappings.md#logical-dir-rules)を参照してください。 + 仮想ディレクトリの構造の詳細については、「」を参照してください[仮想ディレクトリ構造](implement-log-dirs.md#virtual-dirs)。 ### カスタム ID プロバイダーに関する考慮事項 カスタム ID プロバイダーを使用する場合、LOGICAL HomeDirectory HomeDirectoryType を指定できるようになりました。TestIdentityProvider API コールは、カスタム IDP が LOGICAL モードで HomeDirectory を指定すると、正しい結果を生成します。 HomeDirectory と LOGICAL HomeDirectoryType を使用したカスタム IDP レスポンスの例: ``` { "Role": "arn:aws:iam::123456789012:role/transfer-user-role", "HomeDirectoryType": "LOGICAL", "HomeDirectory": "/marketing", "HomeDirectoryDetails": "[{\"Entry\":\"/\",\"Target\":\"/bucket/home\"},{\"Entry\":\"/marketing\",\"Target\":\"/marketing-bucket/campaigns\"}]" } ``` ## Active Directory グループクォータ AWS Transfer Family のデフォルト制限は、サーバーあたり 100 Active Directory グループです。ユースケースで 100 を超えるグループが必要な場合は、「 のカスタム ID プロバイダー[を使用した Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダー AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)ソリューションの使用を検討してください。 この制限は、次の ID プロバイダーを使用するサーバーに適用されます。 + AWS Directory Service for Microsoft Active Directory + AWS Entra ID ドメインサービスの Directory Service サービス制限の引き上げをリクエストする必要がある場合は、「」の[AWS のサービス 「クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください*AWS 全般のリファレンス*。ユースケースで 100 を超えるグループが必要な場合は、「 のカスタム ID プロバイダー[を使用した Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダー AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)ソリューションの使用を検討してください。 Active Directory グループの制限に関するトラブルシューティング情報については、「」を参照してください[Active Directory グループの制限を超えました](auth-issues.md#managed-ad-group-limits)。 **Topics** + [Amazon EFS と Amazon S3 の比較](#efs-vs-s3-users) + [論理ディレクトリ](#logical-dir-users) + [Active Directory グループクォータ](#ad-group-quotas) + [サービスマネージドユーザーの使用](service-managed-users.md) + [カスタム ID プロバイダーの使用](custom-idp-intro.md) + [AWS Directory Service for Microsoft Active Directory の使用](directory-services-users.md) + [AWS Directory Service for Entra ID ドメインサービスの使用](azure-sftp.md) # サービスマネージドユーザーの使用 サーバーの**ドメイン**設定に応じて、Amazon S3 または Amazon EFS いずれかのサービスマネージドユーザーをサーバーに追加できます。詳細については、「[SFTP、FTPS、または FTP サーバーエンドポイントの設定](tf-server-endpoint.md)」を参照してください。 サービス管理型 ID タイプを使用する場合は、ファイル転送プロトコル対応のサーバーにユーザーを追加します。その場合、各ユーザー名はサーバーで一意である必要があります。 サービス管理ユーザーをプログラムで追加するには、[「CreateUser API」](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html) の[「例」 ](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_Examples)を参照してください。 **注記** サービスマネージドユーザーの場合、論理ディレクトリエントリは 2,000 に制限されています。論理ディレクトリの使用については、「」を参照してください[論理ディレクトリを使用して Transfer Family ディレクトリ構造を簡素化する](logical-dir-mappings.md)。 **Topics** + [Amazon S3 サービスマネージドユーザーの追加](#add-s3-user) + [Amazon EFS サービスマネージドユーザーの追加](#add-efs-user) + [サービスマネージドユーザーの管理](#managing-service-managed-users) ## Amazon S3 サービスマネージドユーザーの追加 **注記** クロスアカウント Amazon S3 バケットを設定する場合は、ナレッジセンターの記事[「別の AWS アカウントにある Amazon Simple Storage Service バケットを使用するように AWS Transfer Family サーバーを設定するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/sftp-cross-account-s3-bucket/)」に記載されているステップに従います。 **Amazon S3 サービスマネージドユーザーをサーバーに追加するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開き、ナビゲーションペインから**サーバー**を選択します。 1. [**Servers**] (サーバー) ページで、ユーザーの追加先になるサーバーのチェックボックスをオンにします。 1. [**Add user**] (ユーザーを追加) を選択します。 1. [**ユーザー設定**] セクションの[**ユーザー名**] にユーザー名を入力します。このユーザー名は最低 3 文字、最高 100 文字である必要があります。ユーザー名には、a～z、A～Z、0～9、アンダースコア '\$1'、ハイフン '-'、ピリオド '.'、アットマーク '@' を使用できます。ユーザー名はハイフン '-'、ピリオド '.'、またはアットマーク '@' で始めることはできません。 1. **[Access]** (アクセス) で、以前に作成した Amazon S3 バケットへのアクセスを提供する IAM ロールを選択します。 この IAM ロールは、「[IAM ポリシーとロールを作成する](requirements-roles.md)」の手順に従って作成されました。その IAM ロールには、Amazon S3 バケットへのアクセスを提供する IAM ポリシーが含まれます。また、別の IAM ポリシーで定義されている AWS Transfer Family サービスとの信頼関係も含まれます。ユーザーに対してきめ細かなアクセスコントロールが必要な場合は、「 [によるデータアクセスコントロールの強化 AWS Transfer Family 」およびAmazon S3](https://aws.amazon.com/blogs/storage/enhance-data-access-control-with-aws-transfer-family-and-amazon-s3-access-points/)ブログ記事」を参照してください。 1. （オプション）「**Policy**」では、以下のいずれかを選択する： + **None** (なし) + **Existing policy** (既存のポリシー) + 「**IAM からポリシーを選択する**」：既存のセッションポリシーを選択できます。[**View**] (表示) を選択すると、ポリシーの詳細を含む JSON オブジェクトが表示されます。 + **[ホームフォルダーに基づいてポリシーを自動生成]**:セッションポリシーを生成します。[**View**] (表示) を選択すると、ポリシーの詳細を含む JSON オブジェクトが表示されます。 **注記** **[ホームフォルダーに基づいてポリシーを自動生成]** を選択した場合は、**[このユーザーに対して制限付き]** を選択しないでください。 セッションポリシーの詳細については、[IAM ポリシーとロールを作成する](requirements-roles.md)「」、[Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md)「」、または「」を参照してください[動的なアクセス許可管理アプローチ](dynamic-permission-management.md)。 1. Home **ディレクトリ**で、転送するデータを保存する Amazon S3 バケットを選択します AWS Transfer Family。ユーザーが SFTP クライアントを使用してログインしたときにアクセスする `home` ディレクトリのパスを入力します。 このパラメータを空白のままにした場合、Amazon S3 バケットの `root` ディレクトリが使用されます。この場合、IAM ロールが `root` ディレクトリへのアクセスを提供することを確認します。 **注記** セッションポリシーを効果的に使用できるように、ユーザーのユーザー名が含まれるディレクトリパスを選択することをお勧めします。セッションポリシーは、Amazon S3 バケットでのユーザーアクセスを `home` ディレクトリに制限します。 1. (オプション) [**Restricted**] (制限) チェックボックスをオンにすると、ユーザーはそのフォルダの外部にあるものにアクセスしたり、Amazon S3 バケット名やフォルダ名を表示したりできなくなります。 **注記** ユーザーにホームディレクトリを割り当て、そのホームディレクトリへのアクセスを制限すれば、指定されたフォルダへのアクセスをロックダウンするのに十分なはずです。さらにコントロールの適用が必要な場合、セッションポリシーを使用します。 このユーザーに対して **[制限付き]** を選択した場合、ホーム フォルダーは制限付きユーザーに対して定義された値ではないため、**[ホーム フォルダーに基づいてポリシーを自動生成]** を選択できません。 1. [**SSH public key**] (SSH 公開キー) に SSH キーペアの SSH 公開キー部分を入力します。 新しいユーザーを追加する前に、サービスによってキーが検証されます。 **注記** SSH キーペアを生成する手順については、「[サービス管理ユーザーの SSH キーの生成](sshkeygen.md)」を参照してください。 1. (オプション) [**Key**] (キー) と [**Value**] (値) にキーバリューペアとして 1 つ以上のタグを入力して [**Add tag**] (タグの追加) を選択します。 1. [**Add**] (追加) を選択して、選択したサーバーに新しいユーザーを追加します。 [**Server details**] (サーバーの詳細) ページの [**Users**] (ユーザー) セクションに新しいユーザーが表示されます。 **次のステップ**— 次のステップについては、「[クライアントを使用してサーバーエンドポイント経由でファイルを転送する](transfer-file.md)」に進みます。 ## Amazon EFS サービスマネージドユーザーの追加 Amazon EFS は、Portable Operating System Interface (POSIX) ファイルアクセス許可モデルを使用して、ファイルの所有権を表します。 + Amazon EFS ファイルの所有権の詳細については、「[Amazon EFS ファイルの所有権](configure-storage.md#efs-file-ownership)」を参照してください。 + EFS ユーザー向けのディレクトリの設定に関する詳細は、[Transfer Family用にAmazon EFSユーザーを設定します。](configure-storage.md#configure-efs-users-permissions) を参照してください。 **Amazon EFS サービスマネージドユーザーをサーバーに追加するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開き、ナビゲーションペインから**サーバー**を選択します。 1. [**Servers**] (サーバー) ページで、ユーザーの追加先になる Amazon EFS サーバーのチェックボックスをオンにします。 1. [**Add user**] (ユーザーの追加) を選択して [**Add user**] (ユーザーの追加) ページを表示します。 1. [**User configuration**] (ユーザー設定) セクションで、次のように設定します。 1. [**ユーザー名**] は、最小 3 文字、最大 100 文字にする必要があります。ユーザー名に使用できる文字は、a-z、A-Z、0-9、アンダースコア「\$1」、ハイフン「-」、ピリオド「.」、およびアットマーク「@」です。ユーザー名をハイフン「-」、ピリオド「.」、アットマーク「@」で始めることはできません。 1. **ユーザー ID** および**グループ ID** については、以下の点に注意してください。 + 最初に作成するユーザーには、**グループ ID** と**ユーザー ID** の両方に **0** の値を入力することをお勧めします。これにより、Amazon EFS のユーザー管理者権限が付与されます。 + 追加のユーザーについて、ユーザーの POSIX ユーザー ID とグループ ID を入力します。これらの ID は、ユーザーが実行するすべての Amazon Elastic File System オペレーションに使用されます。 + [**User ID**] (ユーザー ID) と [**Group ID**] (グループ ID) には、先頭にゼロを使用しないでください。たとえば、**12345** は許容されますが **012345** は許容されません。 1. (オプション) [**Secondary Group IDs**] (セカンダリグループ ID) には、ユーザーごとに 1 つ以上の追加の POSIX グループ ID をカンマで区切って入力します。 1. [**Access**] (アクセス) で、以下のような IAM ロールを選択します。 + アクセスしたい Amazon EFS リソース (ファイルシステム) にのみアクセス権を付与します。 + ユーザーが実行できるファイルシステム操作と実行できないファイルシステムシステムオペレーションを定義します。 Amazon EFS ファイルシステムの選択にあたっては、マウントアクセスと読み書きアクセス許可を持つ IAM ロールを使用することをお勧めします。例えば、次の 2 つの AWS 管理ポリシーの組み合わせは、かなり許容されますが、 はユーザーに必要なアクセス許可を付与します。 + AmazonElasticFileSystemClientFullAccess + AWSTransferConsoleFullAccess 詳細は、ブログ記事「[Amazon Elastic File SystemのAWS Transfer Family 対応](https://aws.amazon.com/blogs/aws/new-aws-transfer-family-support-for-amazon-elastic-file-system/)」を参照してください。 1. [**Home directory**] (ホームディレクトリ) について、次のように操作します。 + AWS Transfer Familyで転送するデータの保存に使用したい Amazon EFS ファイルシステムを選択します。 + ホームディレクトリを**制限**するかどうかを決めます。ホームディレクトリを [**Restricted**] (制限) に設定すると次の効果があります。 + Amazon EFS ユーザーは、そのフォルダ外のファイルやディレクトリにアクセスできません。 + Amazon EFS ユーザーは Amazon EFS ファイルシステム名 (**fs-xxxxxxx**) を表示できません。 **注記** [**Restricted**] (制限) オプションを使用すると、Amazon EFS ユーザーのシンボリックリンクは解決されません。 + (オプション) ユーザーがクライアントとしてログインしたときのホームディレクトリのパスを入力します。 ホームディレクトリを指定しない場合、Amazon EFS ファイルシステムのルートディレクトリが使用されます。この場合、IAM ロールがルートディレクトリへのアクセスを提供することを確認します。 1. [**SSH public key**] (SSH パブリックキー) に SSH キーペアの SSH パブリックキー部分を入力します。 新しいユーザーを追加する前に、サービスによってキーが検証されます。 **注記** SSH キーペアを生成する手順については、「[サービス管理ユーザーの SSH キーの生成](sshkeygen.md)」を参照してください。 1. (オプション) ユーザーに任意のタグを入力します。[**Key**] (キー) と [**Value**] (値) にキーバリューペアとして 1 つ以上のタグを入力して [**Add tag**] (タグの追加) を選択します。 1. [**Add**] (追加) を選択して、選択したサーバーに新しいユーザーを追加します。 [**Server details**] (サーバーの詳細) ページの [**Users**] (ユーザー) セクションに新しいユーザーが表示されます。 初めて SFTP で Transfer Family サーバーに接続する際に発生する可能性がある問題: + `sftp` コマンドを実行した場合にプロンプトが表示されず、次のメッセージが表示されることがあります。 `Couldn't canonicalize: Permission denied` `Need cwd` この場合、ユーザーのロールのポリシー許可を増やす必要があります。などの AWS 管理ポリシーを追加できます`AmazonElasticFileSystemClientFullAccess`。 + `sftp` プロンプトで `pwd` を入力してユーザーのホームディレクトリを表示すると、以下のようなメッセージが表示されます。*USER-HOME-DIRECTORY*は SFTP ユーザーのホームディレクトリです。 `remote readdir("/USER-HOME-DIRECTORY"): No such file or directory` この場合、親ディレクトリ (`cd ..`) をクリックし、ユーザーのホームディレクトリ (`mkdir username`) を作成します。 **次のステップ**— 次のステップについては、「[クライアントを使用してサーバーエンドポイント経由でファイルを転送する](transfer-file.md)」に進みます。 ## サービスマネージドユーザーの管理 このセクションでは、ユーザーのリストを表示する方法、ユーザーの詳細を編集する方法、および SSH パブリックキーを追加する方法について説明します。 + [ユーザーリストを表示する](#list-users) + [ユーザーの詳細を表示または編集する](#view-user-details) + [ユーザーを削除する](#delete-user) + [SSH パブリックキーを追加する](#add-user-ssh-key) + [SSH パブリックキーを削除する](#delete-user-ssh-key) **ユーザーのリストを検索するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. ナビゲーションペインで [**Servers**] (サーバー) を選択して [**Servers**] (サーバー) ページを表示します。 1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。 1. [**Users**] (ユーザー) の下にユーザーのリストが表示されます。 **ユーザーの詳細を表示または編集するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. ナビゲーションペインで [**Servers**] (サーバー) を選択して [**Servers**] (サーバー) ページを表示します。 1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。 1. [**ユーザー**] でユーザー名を選択し、[**ユーザーの詳細**] ページを見ます。 このページで [**Edit**] (編集) を選択すると、ユーザーのプロパティを変更できます。 1. [**User details**] (ユーザーの詳細) ページで [**User configuration**] (ユーザー設定) の隣にある [**Edit**] (編集) を選択します。 ![\[ユーザーの構成を編集する画面を示す画像\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-user-details-page-user-config.png) 1. [**Edit onfigu**] (設定の編集) ページで [**Access**] (アクセス) について、以前に作成した Amazon S3 バケットへのアクセスを提供する IAM ロールを選択します。 この IAM ロールは、「[IAM ポリシーとロールを作成する](requirements-roles.md)」の手順に従って作成されました。その IAM ロールには、Amazon S3 バケットへのアクセスを提供する IAM ポリシーが含まれます。また、別の IAM ポリシーで定義されている AWS Transfer Family サービスとの信頼関係も含まれます。 1. (オプション) [**Policy**] (ポリシー) で、次のいずれかを選択します。 + **None** (なし) + **Existing policy** (既存のポリシー) + 既存のポリシーを選択するには、**IAM からから ポリシーを選択**します。[**View**] (表示) を選択すると、ポリシーの詳細を含む JSON オブジェクトが表示されます。 セッションポリシーの詳細については、「[IAM ポリシーとロールを作成する](requirements-roles.md)」を参照してください。セッションポリシーの作成方法の詳細については、「[Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md)」を参照してください 。 1. Home **ディレクトリ**で、転送するデータを保存する Amazon S3 バケットを選択します AWS Transfer Family。ユーザーが SFTP クライアントを使用してログインしたときにアクセスする `home` ディレクトリのパスを入力します。 このパラメータを空白のままにした場合、Amazon S3 バケットの `root` ディレクトリが使用されます。この場合、IAM ロールが `root` ディレクトリへのアクセスを提供することを確認します。 **注記** セッションポリシーを効果的に使用できるように、ユーザーのユーザー名が含まれるディレクトリパスを選択することをお勧めします。セッションポリシーは、Amazon S3 バケットでのユーザーアクセスを `home` ディレクトリに制限します。 1. (オプション) [**Restricted**] (制限) チェックボックスをオンにすると、ユーザーはそのフォルダの外部にあるものにアクセスしたり、Amazon S3 バケット名やフォルダ名を表示したりできなくなります。 **注記** ユーザーにホームディレクトリを割り当てて、ユーザーをそのホームディレクトリに制限する場合、指定したフォルダへのユーザーのアクセスをロックダウンするにはこれで十分なはずです。さらなるコントロールの適用が必要な場合、セッションポリシーを使用します。 1. [**Save**] (保存) を選択して変更内容を保存します。 **ユーザーを削除するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. ナビゲーションペインで [**Servers**] (サーバー) を選択して [**Servers**] (サーバー) ページを表示します。 1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。 1. [**ユーザー**] でユーザー名を選択し、[**ユーザーの詳細**] ページを見ます。 1. [**ユーザーの詳細**] ページで、ユーザー名の右にある[**削除**] を選択します。 1. 表示される確認ダイアログボックスで、「**delete**」という語を入力してから [**Delete**] (削除) を選択してユーザーを削除してよいことを確認します。 [**Users**] (ユーザー) リストからユーザーが削除されます。 **ユーザーの SSH パブリックキーを追加するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. ナビゲーションペインで、[**Servers**] (サーバー) を選択します。 1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。 1. [**ユーザー**] でユーザー名を選択し、[**ユーザーの詳細**] ページを見ます。 1. [**Add SSH public key**] (SSH パブリックキーの追加) を選択して、新しい SSH パブリックキーをユーザーに追加します。 **注記** SSH キーは、Secure Shell（SSH）File Transfer Protocol (SFTP)が有効になっているサーバーでのみ使用されます。SSH キーペアを生成する方法については、「[サービス管理ユーザーの SSH キーの生成](sshkeygen.md)」を参照してください。 1. [**SSH public key**] (SSH パブリックキー) に SSH キーペアの SSH パブリックキー部分を入力します。 新しいユーザーを追加する前に、サービスによってキーが検証されます。SSH キーの形式は `ssh-rsa string` です。SSH キーペアを生成するには、「[サービス管理ユーザーの SSH キーの生成](sshkeygen.md)」を参照してください。 1. [**Add key**] (キーの追加) を選択します。 **ユーザーの SSH パブリックキーを削除するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. ナビゲーションペインで、[**Servers**] (サーバー) を選択します。 1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。 1. [**ユーザー**] でユーザー名を選択し、[**ユーザーの詳細**] ページを見ます。 1. パブリックキーを削除するには、その SSH キーチェックボックスを選択し、**削除**を選択します。 # カスタム ID プロバイダーの使用 AWS Transfer Family には、カスタム ID プロバイダーが安全なファイル転送のためにユーザーを認証および認可するためのいくつかのオプションが用意されています。主なアプローチは次のとおりです。 + [カスタム ID プロバイダーソリューション](custom-idp-toolkit.md)— このトピックでは、GitHub でホストされているツールキットを使用して、Transfer Family カスタム ID プロバイダーソリューションについて説明します。 **注記** ほとんどのユースケースでは、これは推奨されるオプションです。具体的には、100 を超える Active Directory グループをサポートする必要がある場合、カスタム ID プロバイダーソリューションは、グループの制限なしにスケーラブルな代替手段を提供します。このソリューションは、ブログ記事[「カスタム ID プロバイダーによる Active Directory 認証の簡素化 AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)」で説明されています。 + [Amazon API Gateway を使用して ID プロバイダーを統合する](authentication-api-gateway.md)— このトピックでは、 AWS Lambda 関数を使用して Amazon API Gateway メソッドをバックアップする方法について説明します。 RESTful インターフェイスは、単一の Amazon API Gateway メソッドで提供できます。Transfer Family は、このメソッドを呼び出して ID プロバイダーに接続し、ID プロバイダーは Amazon S3 または Amazon EFS へのアクセスを認証および承認します。ID プロバイダーを統合するために RESTful API が必要な場合、または AWS WAF を使用してその機能をジオブロッキングまたはレート制限リクエストに活用する場合は、このオプションを使用します。詳細については、「[Amazon API Gateway を使用して ID プロバイダーを統合する](authentication-api-gateway.md)」を参照してください。 + [動的なアクセス許可管理アプローチ](dynamic-permission-management.md)— このトピックでは、セッションポリシーを使用してユーザーアクセス許可を動的に管理する方法について説明します。 ユーザーを認証するには、 AWS Transfer Familyで既存の ID プロバイダーを使用します。ID プロバイダーを統合するには、 AWS Lambda 関数を使用して、Amazon S3 または Amazon Elastic File System (Amazon EFS) へのアクセス権を認証および承認します。詳細については、「[AWS Lambda を使用して ID プロバイダーを統合する](custom-lambda-idp.md)」を参照してください。また、 AWS Transfer Family Management Console では、ファイル数や転送バイト数などのメトリクスに関する CloudWatch グラフにアクセスすることができ、一元化されたダッシュボードを使用してファイル転送を監視するための単一ペインを提供します。 + Transfer Family は、ブログ投稿と、ファイル転送ソリューションの構築を案内するワークショップを提供します。このソリューションは、 AWS Transfer Family マネージド SFTP/FTPS エンドポイントに 、ユーザー管理に Amazon Cognito と DynamoDB を活用します。 ブログ記事は、 [AWS Transfer Family および Amazon S3 での ID プロバイダーとしての Amazon Cognito Amazon S3](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/)の使用で入手できます。ワークショップの詳細については、[こちらを参照してください](https://catalog.workshops.aws/transfer-family-sftp/en-US)。 **注記** カスタム ID プロバイダーの場合、ユーザー名は 3 ～ 100 文字である必要があります。ユーザー名には、a～z、A～Z、0～9、アンダースコア「\$1」、ハイフン「-」、ピリオド「.」、アットマーク「@」を使用できます。ユーザー名は、ハイフン '-'、ピリオド '.'、またはアットマーク '@' で始めることはできません。 カスタム ID プロバイダーを実装するときは、次のベストプラクティスを考慮してください。 + Transfer Family サーバーと同じ AWS アカウント およびリージョンにソリューションをデプロイします。 + IAM ロールとポリシーを設定するときに、最小特権の原則を実装します。 + セキュリティを強化するために、IP 許可リストや標準化されたログ記録などの機能を使用します。 + デプロイ前に、非本番環境でカスタム ID プロバイダーを徹底的にテストします。 **Topics** + [カスタム ID プロバイダーソリューション](custom-idp-toolkit.md) + [AWS Lambda を使用して ID プロバイダーを統合する](custom-lambda-idp.md) + [Amazon API Gateway を使用して ID プロバイダーを統合する](authentication-api-gateway.md) + [複数の認証方法の使用](custom-idp-mfa.md) + [カスタム ID プロバイダーの IPv6 サポート](custom-idp-ipv6.md) # カスタム ID プロバイダーソリューション AWS Transfer Family カスタム ID プロバイダーソリューションは、サービスを実装する際に企業が持つ多くの一般的な認証と認可のユースケースを解決するモジュール式のカスタム ID プロバイダーソリューションです。このソリューションは、ユーザーごとの詳細なセッション設定でカスタム ID プロバイダーを実装するための再利用可能な基盤を提供し、認証ロジックと認可ロジックを分離して、さまざまなユースケース向けに柔軟でeasy-to-maintain基盤を提供します。 AWS Transfer Family カスタム ID プロバイダーソリューションを使用すると、一般的なエンタープライズ認証と認可のユースケースに対処できます。このモジュラーソリューションは以下を提供します。 + カスタム ID プロバイダーを実装するための再利用可能な基盤 + ユーザーごとの詳細なセッション設定 + 認証ロジックと認可ロジックを分離 ## カスタム ID ツールキットの実装の詳細 このソリューションは、さまざまなユースケースに柔軟で保守可能なベースを提供します。開始するには、[https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family) でツールキットを確認し、[「開始方法](https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp#getting-started)」セクションのデプロイ手順に従ってください。 ![\[GitHub で利用可能なカスタム ID プロバイダーツールキットのアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/custom-idp-solution-high-level-architecture.png) **注記** カスタム ID プロバイダーのテンプレートと例を以前に使用したことがある場合は、代わりにこのソリューションを採用することを検討してください。今後、プロバイダー固有のモジュールはこのソリューションで標準化されます。このソリューションには、継続的なメンテナンスと機能強化が適用されます。 このソリューションには、 `HomeDirectoryDetails`パラメータなど AWS Transfer Family、ログ記録や必要な追加のセッションメタデータの保存先などの詳細を説明するカスタムプロバイダーを実装するための標準パターンが含まれています。このソリューションは、ユーザーごとの詳細なセッション設定でカスタム ID プロバイダーを実装するための再利用可能な基盤を提供し、認証を完了してセッションの設定を確立するために Transfer Family に返される設定を構築する再利用可能なロジックから ID プロバイダー認証ロジックを切り離します。 このソリューションのコードとサポートリソースは、[https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family) で入手できます。 ツールキットには次の機能が含まれています。 + 必要なリソースをプロビジョニングする[AWS Serverless Application Model](https://aws.amazon.com/serverless/sam)テンプレート。必要に応じて、ブログ記事「Securing with Web Application Firewall and Amazon API Gateway」で説明されているように AWS WAF、Amazon API Gateway をデプロイして設定します。 [AWS Transfer FamilyAWS Amazon API Gateway](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) + `HomeDirectoryDetails`、、 などのユーザーセッション設定など、ID プロバイダーに関する設定メタデータを保存する [Amazon DynamoDB](https://aws.amazon.com/dynamodb) スキーマ`Policy`。 `Role` + モジュールとして、将来的に新しい ID プロバイダーをソリューションに追加できるモジュラーアプローチ。 + 属性の取得: 必要に応じて、AD、LDAP、Okta などのサポートされている ID プロバイダーから IAM ロールと POSIX プロファイル (UID と GID) 属性を取得します。 + ソリューションの同じデプロイを使用して、単一の Transfer Family サーバーと複数の Transfer Family サーバーに接続された複数の ID プロバイダーのサポート。 + ユーザーごとまたは ID プロバイダーごとにオプションで設定できる IP 許可リストなどの組み込み IP 許可リストチェック。 + 詳細なログ記録と設定可能なログレベル、およびトラブルシューティングに役立つトレースのサポート。 カスタム ID プロバイダーソリューションをデプロイする前に、次の AWS リソースが必要です。 + NAT ゲートウェイまたは DynamoDB ゲートウェイエンドポイントを介したインターネット接続を備えた、プライベートサブネットを持つ Amazon Virtual Private Cloud (VPC)。 + 以下のタスクを実行するための適切な IAM アクセス許可。 + `custom-idp.yaml` CloudFormation テンプレートをデプロイします。 + AWS CodePipeline プロジェクトの作成 + AWS CodeBuild プロジェクトを作成する + IAM ロールとポリシーを作成する **重要** ターゲット Transfer Family サーバー AWS リージョン を含む同じ AWS アカウント および にソリューションをデプロイする必要があります。 ## サポートされている ID プロバイダー 次のリストには、カスタム ID プロバイダーソリューションでサポートされている ID プロバイダーの詳細が含まれています。 | プロバイダー | パスワードフロー | パブリックキーフロー | 多要素 | 属性の取得 | 詳細 | | --- | --- | --- | --- | --- | --- | | Active Directory と LDAP | はい | あり | なし | はい | ユーザー検証は、パブリックキー認証フローの一部として実行できます。 | | Argon2 (ローカルハッシュ) | はい | なし | なし | いいえ | Argon2 ハッシュは、「ローカル」パスワードベースの認証ユースケースのユーザーレコードに保存されます。 | | Amazon Cognito | あり | なし | はい\$1 | いいえ | 時間ベースのワンタイムパスワード (TOTP) ベースの多要素認証のみ。 \$1SMS ベースの MFA はサポートされていません。 | | Entra ID (以前の Azure AD) | はい | なし | なし | いいえ | | | Okta | はい | はい | はい\$1 | はい | TOTP ベースの MFA のみ。 | | パブリックキー | いいえ | あり | なし | いいえ | パブリックキーは DynamoDB のユーザーレコードに保存されます。 | | Secrets Manager | はい | あり | なし | いいえ | | # AWS Lambda を使用して ID プロバイダーを統合する このトピックでは、カスタム ID プロバイダーに接続する AWS Lambda 関数を作成する方法について説明します。Okta、Secrets Manager、OneLogin や、認可および認証ロジックを含むカスタムデータストアなど、任意のカスタム ID プロバイダーを使用できます。 ほとんどのユースケースでは、カスタム ID プロバイダーを設定する推奨方法は、 を使用することです[カスタム ID プロバイダーソリューション](custom-idp-toolkit.md)。 **注記** Lambda を ID プロバイダーとして使用する Transfer Family サーバーを作成する前に、関数を作成する必要があります。サンプルの Lambda 関数については、「[Lambda 関数の例](#lambda-auth-examples)」を参照してください。あるいは、いずれかの [Lambda 関数のテンプレート](#lambda-idp-templates) を使用する CloudFormation スタックをデプロイすることもできます。また、Lambda 関数が Transfer Family と信頼関係にあるリソースベースのポリシーを使用していることを確認してください。ポリシーの例については「[Lambda リソースベースのポリシー](#lambda-resource-policy)」を参照してください。 1. [AWS Transfer Family コンソール](https://console.aws.amazon.com/transfer/)を開きます。 1. [**Create server**] (サーバーの作成) を選択すると [**Create server**] (サーバーの作成) ページが開きます。[**Choose an identity provider**] (ID プロバイダーの選択) で [**Custom Identity Provider**] (カスタム ID プロバイダー) を選択します (次の画面例を参照)。 ![\[[ID プロバイダーの選択] コンソールセクションで、[カスタム ID プロバイダー] が選択されています。また、ユーザーはパスワードまたはキーのいずれかを使用して認証できるというデフォルト値が選択されています。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/custom-lambda-console.png) **注記** 認証方法を選択できるのは、Transfer Familyサーバーのプロトコルの1つとしてSFTPを有効にした場合のみです。 1. デフォルト値である ** AWS Lambda を使用して ID プロバイダーを接続します**。 1. 「**AWS Lambda 関数**」では、Lambda 関数の名前を選択します。 1. 残りのフィールドに値を入力してから [**Create server**] (サーバーの作成) を選択します。サーバーを作成するための残りの手順の詳細については、「[SFTP、FTPS、または FTP サーバーエンドポイントの設定](tf-server-endpoint.md)」を参照してください。 ## Lambda リソースベースのポリシー Transfer Family サーバーと Lambda ARN を参照するポリシーが必要です。たとえば、ID プロバイダーに接続する Lambda 関数で次のポリシーを使用できます。ポリシーは、JSON で文字列としてエスケープされます。 **** ``` "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\"}}} ]}" ``` **注記** 上記のポリシー例では、各「*ユーザー入力プレースホルダー*」をあなた自身の情報で置き換えます。 ## イベントメッセージの構造 SFTP サーバーからカスタム IDP のオーソライザー Lambda 関数に送信されるイベントメッセージ構造は次のとおりです。 ``` { "username": "value", "password": "value", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` ここで、`username`および`password`はサーバーに送信されるサインイン認証情報の値です。 例えば、以下のコマンドを入力して接続する： ``` sftp bobusa@server_hostname ``` その後、パスワードの入力を求められる： ``` Enter password: mysecretpassword ``` Lambda 関数内から渡されたイベントを出力することで、Lambda 関数からこれを確認できます。以下のテキストブロックのように見えるはずです。 ``` { "username": "bobusa", "password": "mysecretpassword", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` イベントの構造は FTP と FTPS で似ています。唯一の違いは、SFTP ではなく、これらの値が`protocol`パラメータに使用されることです。 ## 認証用の Lambda 関数 さまざまな認証戦略を実装するには、Lambda 関数を編集します。アプリケーションのニーズを満たすために、CloudFormation スタックをデプロイできます。Lambda の詳細については、[AWS Lambda デベロッパーガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)または「[Node.js による Lambda 関数の構築](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html)」を参照してください。 **Topics** + [有効な Lambda 値](#lambda-valid-values) + [Lambda 関数の例](#lambda-auth-examples) + [設定をテストする](#authentication-test-configuration) + [Lambda 関数のテンプレート](#lambda-idp-templates) ### 有効な Lambda 値 次の表は、カスタム ID プロバイダーに使用される Lambda 関数について Transfer Family が受け入れる値の詳細についての説明です。 | 値 | 説明 | 必須 | | --- | --- | --- | | `Role` | Amazon S3 バケットまたは Amazon EFS ファイルシステムへのユーザーのアクセスを制御する IAM ロールの Amazon Resource Name (ARN) を指定します。このロールにアタッチされたポリシーにより、ファイルを Amazon S3 または Amazon EFS ファイルシステム間で転送する際のユーザーに付与するアクセスのレベルが決定されます。IAM ロールには、ユーザーの転送リクエストを処理する際に、サーバーによるリソースへのアクセスを許可する信頼関係も含まれる必要があります。 信頼関係の確立の詳細については、[信頼関係を確立するには](requirements-roles.md#establish-trust-transfer) を参照してください。 | 必須 | | `PosixProfile` | ユーザーの Amazon EFS ファイルシステムへのアクセスを制御する、ユーザー ID (`Uid`)、グループ ID (`Gid`)、およびセカンダリグループ ID (`SecondaryGids`) を含む完全な POSIX ID。ファイルシステム内のファイルとディレクトリに設定される POSIX アクセス許可によって、Amazon EFS ファイルシステムとの間でファイルを転送するときにユーザーが得るアクセスのレベルが決まります。 | Amazon EFS バッキングストレージに必須 | | `PublicKeys` | このユーザーに有効な SSH パブリックキー値のリスト。空のリストはこれが有効なログインではないことを示します。パスワード認証中に返してはなりません。 | オプションです。 | | `Policy` | 複数のユーザーに同じ IAM ロールの使用を可能にするユーザーのセッションポリシー。このポリシーは、ユーザーアクセスのスコープを Amazon S3 バケットの一部に絞り込みます。カスタム ID プロバイダーでセッションポリシーを使用する方法の詳細については、このトピックのセッションポリシーの例を参照してください。 | オプションです。 | | `HomeDirectoryType` | ユーザーがサーバーにログインするときにホームディレクトリにするランディングディレクトリ (フォルダ) のタイプ。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/custom-lambda-idp.html) | オプションです。 | | `HomeDirectoryDetails` | ユーザーに表示する Amazon S3 または Amazon EFS のパスとキー、およびそれらをどのように表示するかを指定する論理ディレクトリマッピング。「`Entry`」と「`Target`」のペアを指定する必要があり、`Entry` はパスの表示方法を示し、`Target` は実際の Amazon S3 または Amazon EFS のパスです。 | `HomeDirectoryType` に `LOGICAL` の値がある場合に必須 | | `HomeDirectory` | ユーザーがクライアントを使用してサーバーにログインするときの、ユーザーのランディングディレクトリ。形式はストレージバックエンドによって異なります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/custom-lambda-idp.html) バケット名または Amazon EFS ファイルシステム ID をパスに含める必要があります。この情報を省略すると、ファイル転送中に「ファイルが見つかりません」エラーが発生します。 | オプションです。 | **注記** `HomeDirectoryDetails`はJSON マップの文字列表現です。これは、実際のJSONマップ・オブジェクトである`PosixProfile`や、文字列のJSON配列である`PublicKeys`とは対照的です。言語固有の詳細については、コード例を参照してください。 **HomeDirectory 形式の要件** `HomeDirectory` パラメータを使用する場合は、完全なパス形式を含めてください。 **Amazon S3 ストレージの場合:** バケット名は常に 形式で含めます。 `/bucket-name/path` **Amazon EFS ストレージの場合:** ファイルシステム ID は必ず 形式で含めます。 `/fs-12345/path` 「ファイルが見つかりません」エラーの一般的な原因は、`HomeDirectory`パスからバケット名または EFS ファイルシステム ID を省略することです。ストレージ識別子`/`なしで `HomeDirectory`に設定すると、認証は成功しますが、ファイルオペレーションは失敗します。 ### Lambda 関数の例 このセクションでは、NodeJS と Python の両方で使用される Lambda 関数の例をいくつか紹介します。 **注記** これらの例では、ユーザー、ロール、POSIX プロファイル、パスワード、ホームディレクトリの詳細はすべて例であり、実際の値に置き換える必要があります。 ------ #### [ Logical home directory, NodeJS ] 以下の NodeJS サンプル関数は、「[論理ホームディレクトリ](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 ] 以下の NodeJS サンプル関数は、パスベースのホーム・ディレクトリを持つユーザーの詳細を提供します。 ``` // 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 ] 以下の Python サンプル関数は、「[論理ホームディレクトリ](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 ] 以下の Python サンプル関数は、パスベースのホームディレクトリを持つユーザーの詳細を提供します。 ``` # 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 ``` ------ ### 設定をテストする カスタム ID プロバイダーを作成したら、設定をテストする必要があります。 ------ #### [ Console ] **AWS Transfer Family コンソールを使用して設定をテストするには** 1. [AWS Transfer Family コンソール](https://console.aws.amazon.com/transfer/)を開きます。 1. [**Servers**] (サーバー) ページで新しいサーバーを選択し、[**Actions**] (アクション) を選択してから [**Test**] (テスト) を選択します。 1. CloudFormation スタックをデプロイしたときに****設定した**ユーザー名とパスワード**のテキストを入力します。デフォルトのオプションのままだと、ユーザー名は `myuser`、パスワードは `MySuperSecretPassword` となります。 1. CloudFormation スタックのデプロイ時に設定する場合は、**サーバープロトコル**を選択し、**送信元 IP の IP** アドレスを入力します。 ------ #### [ CLI ] **AWS CLI を使用して設定をテストするには** 1. [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html) コマンドを実行します。以降のステップで説明するように、それぞれの `user input placeholder` を独自の情報に置き換えます。 ``` 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. サーバー ID を入力します。 1. CloudFormation スタックをデプロイしたときに設定したユーザー名とパスワードを入力します。デフォルトのオプションのままだと、ユーザー名は `myuser`、パスワードは `MySuperSecretPassword` となります。 1. CloudFormation スタックをデプロイするときに設定する場合は、サーバープロトコルとソース IP アドレスを入力します。 ------ ユーザー認証が成功した場合、テストは`StatusCode: 200` HTTP レスポンス、空の文字列`Message: ""`（これがなければ失敗の理由を含む）、および`Response`フィールドを返します。 **注記** 以下のレスポンス例では、`Response`フィールドは「文字列化」された (プログラム内で使用できるフラットな JSON 文字列に変換された) JSON オブジェクトで、ユーザーのロールと権限の詳細が含まれています。 ``` { "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": "" } ``` ### Lambda 関数のテンプレート 認証に Lambda 関数を使用する CloudFormation スタックをデプロイできます。ログイン認証情報を使用してユーザーを認証および認可するテンプレートがいくつか用意されています。これらのテンプレートまたは AWS Lambda コードを変更して、ユーザーアクセスをさらにカスタマイズできます。 **注記** テンプレートで FIPS 対応セキュリティポリシーを指定 CloudFormation することで、 を使用して FIPS 対応 AWS Transfer Family サーバーを作成できます。使用可能なセキュリティポリシーについては、[AWS Transfer Family サーバーのセキュリティポリシー](security-policies.md)で説明しています。 **認証に使用する CloudFormation スタックを作成するには** 1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。 1. 「 *AWS CloudFormation ユーザーガイド*」の CloudFormation 「スタックテンプレート[の選択」の「既存のテンプレートからスタックを](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html)デプロイする手順」に従います。 1. 以下のテンプレートのいずれかを使用して、Transfer Family で認証に使用するLambda 関数を作成します。 + [クラシック (Amazon Cognito) スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml) でカスタム ID プロバイダーとして使用する AWS Lambda を作成するための基本的なテンプレート AWS Transfer Family。Amazon Cognito に対してパスワードベースの認証を行い、パブリックキーベースの認証が使用されている場合、パブリックキーは Amazon S3 バケットから返されます。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。 + [AWS Secrets Manager スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml) と AWS Transfer Family サーバー AWS Lambda を使用して Secrets Manager を ID プロバイダーとして統合する基本的なテンプレート。形式の AWS Secrets Manager のエントリに対して認証されます`aws/transfer/server-id/username`。さらに、シークレットは、Transfer Family に返されるすべてのユーザープロパティのキーバリューペアを保持する必要があります。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。 + [Okta スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml): を AWS Transfer Family サーバー AWS Lambda で使用する基本テンプレートで、Okta をカスタム ID プロバイダーとして統合します。 + [Okta-mfa スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml): を AWS Transfer Family サーバー AWS Lambda で使用する基本テンプレートで、カスタム ID プロバイダーとして Okta を多要素認証と統合します。 + [ Azure Active Directory テンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml): このスタックの詳細については、ブログ記事[「Authenticating to AWS Transfer Family with Azure Active Directory and AWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/)」を参照してください。 スタックのデプロイ後には、CloudFormation コンソールの [**Output**] (出力) にタブにスタックについての詳細が表示されます。 これらのスタックのいずれかをデプロイすることが、カスタム ID プロバイダーをTransfer Family ワークフローに統合するうえで最も簡単な方法です。 # Amazon API Gateway を使用して ID プロバイダーを統合する このトピックでは、 AWS Lambda 関数を使用して API Gateway メソッドをバックアップする方法について説明します。ID プロバイダーを統合するために RESTful API が必要な場合、または AWS WAF を使用してその機能をジオブロッキングまたはレート制限リクエストに活用する場合は、このオプションを使用します。 ほとんどのユースケースでは、カスタム ID プロバイダーを設定する推奨方法は、 を使用することです[カスタム ID プロバイダーソリューション](custom-idp-toolkit.md)。 「**API ゲートウェイを使用して ID プロバイダを統合する場合の制限事項**」 + この構成はカスタムドメインをサポートしていません。 + この構成は、プライベート API Gateway URL をサポートしていません。 これらのいずれかが必要な場合は、API Gateway なしで Lambda を ID プロバイダーとして使用できます。詳細については、「[AWS Lambda を使用して ID プロバイダーを統合する](custom-lambda-idp.md)」を参照してください。 ## API Gateway メソッドを使用した認証 Transfer Family の ID プロバイダーとして使用する API Gateway メソッドを作成できます。このアプローチは、API を作成して提供するための非常に安全な方法です。API Gateway を使用すると、HTTPS エンドポイントを作成して、すべての受信 API オペレーションをセキュリティを強化して送信できます。API Gateway サービスの詳細については、[API Gateway デベロッパーガイド](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)を参照してください。 API Gateway は、 という名前の認可方法を提供します。これにより`AWS_IAM`、 が内部 AWS で使用する AWS Identity and Access Management (IAM) に基づく認証と同じ認証が提供されます。`AWS_IAM` で認証を有効にした場合、API を呼び出す明示的なアクセス権限を持つ呼び出し側のみがその API Gateway メソッドに到達できます。 API Gateway メソッドをTransfer Family カスタム ID プロバイダーとして使用するには、API Gateway メソッドの IAM を有効にします。このプロセスの一環として、Transfer Family についてゲートウェイを使用するためのアクセス許可を持つ IAM ロールを提供します。 **注記** セキュリティを強化するために、ウェブアプリケーションのファイアウォールを設定できます。 AWS WAF はウェブアプリケーションファイアウォールで、これにより Amazon API Gateway に転送される HTTP および HTTPS リクエストのモニタリングが可能です。詳細については、「[ウェブアプリケーションファイアウォールを追加する](web-application-firewall.md)」を参照してください **API Gateway キャッシュを有効にしない** Transfer Family のカスタム ID プロバイダーとして使用する場合、API Gateway メソッドのキャッシュを有効にしないでください。次の理由により、キャッシュは認証リクエストに対して不適切で無効です。 各認証リクエストは一意であり、キャッシュされたレスポンスではなく、ライブレスポンスが必要です Transfer Family は API Gateway に重複または繰り返しリクエストを送信しないため、キャッシュには利点はありません。 キャッシュを有効にすると、API Gateway が不一致データで応答し、認証リクエストへの無効な応答が発生します。 **Transfer Family でカスタム認証に API Gateway メソッドを使用するには** 1. CloudFormation スタックを作成します。これを実行するには: **注記** スタックテンプレートが更新され、BASE64-encodedパスワードが使用されました。詳細については、「」を参照してください[CloudFormation テンプレートの改善](#base64-templates)。 1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。 1. 「 *AWS CloudFormation ユーザーガイド*」の CloudFormation 「スタックテンプレート[の選択」の「既存のテンプレートからスタックを](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html)デプロイする手順」に従います。 1. 次の基本テンプレートのいずれかを使用して、Transfer Family でカスタム ID プロバイダーとして使用する AWS Lambda Backed API Gateway メソッドを作成します。 + [基本スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-apig.template.yml) デフォルトでは、API Gateway メソッドは、ハードコードされた SSH (Secure Shell) キーまたはパスワードを使用して単一のサーバーで単一のユーザーを認証するカスタム ID プロバイダーとして使用されます。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。 + [AWS Secrets Manager スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml) デフォルトでは、API Gateway メソッドは、Secrets Manager 内の `aws/transfer/server-id/username` 形式のエントリに対して認証します。さらに、シークレットは、Transfer Family に返されるすべてのユーザープロパティのキーバリューペアを保持する必要があります。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。詳細については、ブログ記事[「 AWS Transfer Family を使用したパスワード認証の有効化 AWS Secrets Manager](https://aws.amazon.com/blogs/storage/enable-password-authentication-for-aws-transfer-family-using-aws-secrets-manager-updated/)」を参照してください。 + [Okta スタックテンプレート](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-apig.template.yml) API Gateway メソッドは、Transfer Family のカスタム ID プロバイダーとして Okta と統合されます。詳細については、ブログ記事「[AWS Transfer Familyで Okta を ID プロバイダーとして使う](https://aws.amazon.com/blogs/storage/using-okta-as-an-identity-provider-with-aws-transfer-for-sftp/)」を参照してください。 これらのスタックのいずれかをデプロイすることが、カスタム ID プロバイダーをTransfer Family ワークフローに統合するうえで最も簡単な方法です。各スタックは Lambda 関数を使用して、API Gateway に基づく API メソッドをサポートします。その後、Transfer Family でカスタム ID プロバイダーとして API メソッドを使用できます。デフォルトでは、Lambda 関数は、`myuser` という単一のユーザーを `MySuperSecretPassword` のパスワードで認証します。デプロイ後に、これらの認証情報を編集するか Lambda 関数コードを更新すれば異なる処理を実行できます。 **重要** デフォルトのユーザーとパスワード認証情報を編集することをお勧めします。 スタックのデプロイ後には、CloudFormation コンソールの [**Output**] (出力) にタブにスタックについての詳細が表示されます。具体的には、スタックの Amazon リソースネーム (ARN)、スタックが作成した IAM ロールの ARN、および新しいゲートウェイの URL が含まれます。 **注記** カスタム ID プロバイダーオプションを使用してユーザーのパスワードベースの認証を有効にし、API Gateway によって提供されるリクエストとレスポンスのログを有効にした場合、API Gateway はユーザーのパスワードを Amazon CloudWatch Logs に記録します。本稼働環境でこのログを使用することは推奨されません。詳細については、*API Gateway デベロッパーガイド*の「[API Gateway に CloudWatch API ログ記録を設定する](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html)」を参照してください。 1. サーバーの API Gateway メソッドの設定を確認します。これを実行するには: 1. API Gateway コンソール ([https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway/)) を開きます。 1. CloudFormation テンプレートが生成した **Transfer Custom Identity Provider の基本テンプレート API** を選択します。ゲートウェイを表示するには、リージョンを選択する必要があります。 1. **リソース**ペインで、**GET** を選択します。次の画面例は、正しいメソッド設定を示しています。 ![\[API 設定の詳細には、リクエストパスと URL クエリ文字列のメソッド設定パラメータが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/apig-config-method-fields.png) この時点で、API Gateway をデプロイする準備が整いました。 1. [**Actions**] (アクション) で [**Deploy API**] (API のデプロイ) を選択します。[**Deplyment stage**] (デプロイステージ) で [**prod**] を選択してから [**Deploy**] (デプロイ) を選択します。 API Gateway メソッドが正常にデプロイされたら、次のスクリーンショットに示すように、**ステージ** > **ステージの詳細**でそのパフォーマンスを表示します。 **注記** 画面の最上部に表示される [**Invoke URL**] (呼び出し URL) アドレスをコピーします。次のステップで必要になる場合があります。 ![\[呼び出し URL が強調表示されたステージの詳細。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/apig-config-method-invoke.png) 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. スタックの作成時に Transfer Family が作成されたはずです。そうでない場合は、以下の手順を使用してサーバーを設定します。 1. [**Create server**] (サーバーの作成) を選択すると [**Create server**] (サーバーの作成) ページが開きます。[**Choose an identity provider**] (ID プロバイダーの選択) で [**Custom**] (カスタム) を選択してから、[**Use Amazon API Gateway to connect to your identity provider**] (Amazon API Gateway を使用してアイデンティティプロバイダーに接続する) を選択します (次の画面例を参照)。 ![\[カスタム ID プロバイダーが選択され、ID プロバイダーへの接続用に API Gateway が選択された ID プロバイダー画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/create-server-choose-idp-custom.png) 1. [**Provide an Amazon API Gateway URL**] (Amazon API Gateway URL を指定) テキストボックスに、ステップ 3 で作成した API Gateway エンドポイントの [**Invoke URL**] (呼び出し URL) アドレスを貼り付けます。 1. **ロール** で、 CloudFormation テンプレートによって作成された IAM ロールを選択します。このロールにより、Transfer Family が API Gateway メソッドを呼び出せるようになります。 呼び出しロールには、ステップ 1 で作成した CloudFormation スタック用に選択したスタック名が含まれます。次のような形式です: `CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI` 1. 残りのフィールドに値を入力してから [**Create server**] (サーバーの作成) を選択します。サーバーを作成するための残りの手順の詳細については、「[SFTP、FTPS、または FTP サーバーエンドポイントの設定](tf-server-endpoint.md)」を参照してください。 ## API Gateway メソッドを実装する Transfer Family のカスタム ID プロバイダーを作成するには、API Gateway メソッドで`/servers/serverId/users/username/config` のリソースパスを持つ単一のメソッドを実装する必要があります。`serverId` と `username` の値は RESTful リソースパスから取得されます。また、下図のように、`sourceIp`と`protocol`を「**URL クエリ文字列パラメータ**」として「**メソッドリクエスト**」に追加します。 ![\[GET メソッドの詳細を示す API Gateway のリソース画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/apig-config-method-request.png) **注記** ユーザー名は、最小 3 文字、最大 100 文字にする必要があります。ユーザー名には、a～z、A～Z、0～9、アンダースコア「\$1」、ハイフン「-」、ピリオド「.」、アットマーク「@」を使用できます。ユーザー名は、ハイフン '-'、ピリオド '.'、またはアットマーク '@' で始めることはできません。 Transfer Family がユーザーに代わってパスワード認証を試みると、サービスが `Password:` ヘッダーフィールドを提供します。`Password:` ヘッダーが存在しない場合、Transfer Family はパブリックキー認証でユーザーを認証しようと試みます。 エンドユーザーの認証と認可に ID プロバイダーを使用する場合、エンドユーザーが使用するクライアントの IP アドレスに基づいてアクセスリクエストを許可または拒否できます。この機能を使用すると、S3 バケットまたは Amazon EFS ファイルシステムに保存されたデータに、信頼済みとして指定した IP アドレスからのみ、サポートされているプロトコル経由でアクセスできるようになります。この機能を有効にするには、`sourceIp`をクエリ文字列に含める必要があります。 サーバーで複数のプロトコルを有効にしており、複数のプロトコルで同じユーザー名を使用してアクセスを提供したい場合、各プロトコルに固有の認証情報が ID プロバイダーに設定されている限り、そうすることができます。この機能を有効にするには、RESTful リソースパスに `protocol` 値を含める必要があります。 API Gateway メソッドは常に HTTP ステータスコード `200` を返す必要があります。その他の HTTP ステータスコードは、API へのアクセスエラーがあったことを示します。 **Amazon S3 のレスポンスの例** この例のレスポンス本文は、Amazon S3 では次の形式の JSON ドキュメントになります。 ``` { "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" } ``` **注記** ポリシーは、JSON で文字列としてエスケープされます。例: **** ``` "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\"}] }" ``` 次のレスポンスの例は、論理ホームディレクトリタイプを有するユーザーを示しています。 ``` { "Role": "arn:aws:iam::123456789012:role/transfer-access-role-s3", "HomeDirectoryType":"LOGICAL", "HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/amzn-s3-demo-bucket1\"}]", "PublicKeys":[""] } ``` **Amazon EFS のレスポンスの例** この例のレスポンス本文は、Amazon EFS では次の形式の JSON ドキュメントになります。 ``` { "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" } ``` `Role` フィールドは認証に成功したことを示します。パスワード認証を実行する場合 (`Password:` ヘッダーの提供時) には、SSH パブリックキーを提供する必要はありません。ユーザーが認証できない場合 (たとえば、パスワードが正しくない場合)、メソッドは `Role` を設定せずにレスポンスを返す必要があります。このようなレスポンスの例として、空の JSON オブジェクトがあります。 次のレスポンスの例は、論理ホームディレクトリタイプを持つユーザーを示しています。 ``` { "Role": "arn:aws:iam::123456789012:role/transfer-access-role-efs", "HomeDirectoryType": "LOGICAL", "HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/faa1a123\"}]", "PublicKeys":[""], "PosixProfile":{"Uid":65534,"Gid":65534} } ``` Lambda 関数にユーザーポリシーを JSON 形式で含めることができます。Transfer Family でのユーザーポリシーの設定の詳細については、「[アクセスコントロールの管理](users-policies.md)」を参照してください。 ## デフォルトの Lambda 関数 異なる認証戦略を実装するには、ゲートウェイで使用する Lambda 関数を編集します。アプリケーションのニーズを満たすために、Node.js 内で次の Lambda 関数の例を使用できます。Lambda の詳細については、[AWS Lambda デベロッパーガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)または「[Node.js による Lambda 関数の構築](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html)」を参照してください。 以下の Lambda 関数の例では、ユーザー名、パスワード（パスワード認証を行っている場合）、サーバー ID、プロトコル、クライアント IP アドレスを受け取っています。これらの入力を組み合わせて使用すると、ID プロバイダーを検索し、ログインを許可するかどうかを判断できます。 **注記** サーバーで複数のプロトコルを有効にしており、複数のプロトコルで同じユーザー名を使用してアクセスを提供したい場合、プロトコルに固有の認証情報が ID プロバイダーに設定されている限り、そうすることができます。 File Transfer Protocol (FTP) については、Secure Shell (SSH) File Transfer Protocol (SFTP) and File Transfer Protocol over SSL (FTPS) とは異なる認証情報を維持することをお勧めします。SFTP や FTPS と異なり、FTP は認証情報を平文で送信します。FTP の認証情報を SFTP または FTPS から隔離することを推奨します。そうすれば、FTP の認証情報が共有または公開されても、SFTP または FTPS を使用しているワークロードは引き続き安全だからです。 この関数の例は、ロールと論理ホームディレクトリの詳細、ならびに (公開鍵認証を実行する場合には) パブリックキーを返します。 サービス管理対象ユーザーを作成するときは、そのユーザーのホームディレクトリを論理ディレクトリまたは物理ディレクトリに設定します。同様に、目的のユーザーに物理的または論理的なディレクトリ構造を伝えるには、Lambda 関数の結果が必要です。設定するパラメータは [[HomeDirectoryType]](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType) フィールドの値によって異なります。 + `HomeDirectoryType`が`PATH`に設定される場合 — `HomeDirectory`フィールドはユーザーに表示される Amazon S3 バケットの絶対プレフィックスまたは Amazon EFS 絶対パスである必要があります。 + `HomeDirectoryType`が`LOGICAL`に設定される場合 — `HomeDirectory`フィールドを設定「*しないで*」ください。代わりに、サービス管理対象ユーザー向けの [[HomeDirectoryDetails]](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings) パラメーターで説明されている値と同様に、必要なエントリ/ターゲットのマッピングを提供する`HomeDirectoryDetails`フィールドを設定します。 関数の例は[Lambda 関数の例](custom-lambda-idp.md#lambda-auth-examples)に記載されています。 ## で使用する Lambda 関数 AWS Secrets Manager ID プロバイダー AWS Secrets Manager として を使用するには、サンプル CloudFormation テンプレートで Lambda 関数を使用できます。Lambda 関数は、認証情報を使用して Secrets Manager サービスにクエリを実行し、成功すると指定されたシークレットを返します。Secrets Manager の詳細については、[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)を参照してください。 この Lambda 関数を使用するサンプル CloudFormation テンプレートをダウンロードするには、 [が提供する Amazon S3 バケット AWS Transfer Family](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml)に移動します。 ## CloudFormation テンプレートの改善 API Gateway インターフェイスが公開されている CloudFormation テンプレートに改善されました。テンプレートは、API Gateway で BASE64-encodedされたパスワードを使用するようになりました。既存のデプロイは、この機能強化なしで引き続き機能しますが、基本的な US-ASCII 文字セット外の文字を含むパスワードは許可されません。 この機能を有効にするテンプレートの変更は次のとおりです。 + `GetUserConfigRequest AWS::ApiGateway::Method` リソースにはこの`RequestTemplates`コードが必要です (斜体の行は更新された行です) ``` 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')" } ``` + `PasswordBase64` ヘッダーを使用するには、`GetUserConfig`リソース`RequestParameters`の を変更する必要があります (斜体の行は更新された行です）。 ``` RequestParameters: method.request.header.PasswordBase64: false method.request.querystring.protocol: false method.request.querystring.sourceIp: false ``` **スタックのテンプレートが最新かどうかを確認するには** 1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。 1. スタックのリストから、スタックを選択します。 1. 詳細パネルから、**テンプレート**タブを選択します。 1. 以下を探します。 + を検索し`RequestTemplates`、次の行があることを確認します。 ``` "password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")", ``` + を検索し`RequestParameters`、次の行があることを確認します。 ``` method.request.header.PasswordBase64: false ``` 更新された行が表示されない場合は、スタックを編集します。 CloudFormation スタックを更新する方法の詳細については、「 *AWS CloudFormationユーザーガイド*[」の「スタックテンプレートの変更](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-get-template.html)」を参照してください。 # 複数の認証方法の使用 Transfer Family サーバーは、複数の認証方法を使用するときに AND ロジックを制御します。Transfer Family は、これをカスタム ID プロバイダーへの 2 つの個別のリクエストとして扱います。ただし、その効果は結合されます。 認証を完了できるように、両方のリクエストは正しいレスポンスで正常に返される必要があります。Transfer Family では、2 つのレスポンスを完了する必要があります。つまり、必要なすべての要素 (Amazon EFS をストレージに使用する場合、ロール、ホームディレクトリ、ポリシー、POSIX プロファイル) が含まれます。Transfer Family では、パスワードレスポンスにパブリックキーを含めないようにする必要があります。 パブリックキーリクエストには、ID プロバイダーからの別のレスポンスが必要です。**パスワード、キー**、または**パスワードとキー**を使用する場合、その動作は変更されません。 SSH/SFTP プロトコルは、最初にパブリックキー認証を使用してソフトウェアクライアントにチャレンジし、次にパスワード認証をリクエストします。このオペレーションでは、ユーザーが認証を完了する前に、両方が成功することを義務付けています。 カスタム ID プロバイダーオプションでは、認証方法に次のいずれかのオプションを指定できます。 + **パスワードまたはキー** – ユーザーはパスワードまたはキーを使用して認証できます。これは、デフォルト値です。 + **パスワードのみ** – ユーザーは接続するためにパスワードを入力する必要があります。 + **キーのみ** – ユーザーは接続するためにプライベートキーを指定する必要があります。 + **パスワードとキー** – ユーザーは接続するためにプライベートキーとパスワードの両方を指定する必要があります。サーバーは最初にキーを確認し、キーが有効な場合はパスワードの入力を求めます。提供されたプライベートキーが保存されたパブリックキーと一致しない場合、認証は失敗します。 # カスタム ID プロバイダーの IPv6 サポート AWS Transfer Family カスタム ID プロバイダーは IPv6 接続を完全にサポートしています。カスタム ID プロバイダーを実装する場合、Lambda 関数は IPv4 クライアントと IPv6 クライアントの両方から認証リクエストを受信して処理できます。追加の設定は必要ありません。Lambda 関数は、リクエストの `sourceIp`フィールドでクライアントの IP アドレスを受け取ります。IPv4 アドレス ( など`203.0.113.42`) または IPv6 アドレス ( など) です`2001:db8:85a3:8d3:1319:8a2e:370:7348`。カスタム ID プロバイダーの実装では、両方のアドレス形式を適切に処理する必要があります。 **重要** カスタム ID プロバイダーが IP ベースの検証またはログ記録を実行する場合は、実装が IPv6 アドレス形式を適切に処理していることを確認します。IPv6 アドレスは IPv4 アドレスよりも長く、別の表記形式を使用します。 **注記** カスタム ID プロバイダーで IPv6 アドレスを処理するときは、単純な文字列比較ではなく、適切な IPv6 アドレス解析関数を使用していることを確認してください。IPv6 アドレスは、さまざまな正規形式 ( `fd00:b600::ec2`や など`fd00:b600:0:0:0:0:0:ec2`) で表現できます。実装言語で適切な IPv6 アドレスライブラリまたは関数を使用して、IPv6 アドレスを正しく検証して比較します。 **Example カスタム ID プロバイダーでの IPv4 アドレスと IPv6 アドレスの両方の処理** ``` 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" } ``` カスタム ID プロバイダーの実装の詳細については、「」を参照してください[AWS Lambda を使用して ID プロバイダーを統合する](custom-lambda-idp.md)。 # AWS Directory Service for Microsoft Active Directory の使用 を使用して AWS Transfer Family ファイル転送のエンドユーザーを認証できます AWS Directory Service for Microsoft Active Directory。そうすることで、エンドユーザーの認証情報を変更したり、カスタムオーソライザーを必要とせずに、Active Directory 認証に依存するファイル転送ワークフローをシームレスに移行できます。 を使用すると AWS Managed Microsoft AD、Amazon Simple Storage Service (Amazon S3) または Amazon Elastic File System (Amazon EFS) に保存されているデータの SFTP、FTPS、および FTP を介したアクセスを Directory Service ユーザーとグループに安全に提供できます。 Amazon Elastic File System Active Directory を使用してユーザーの認証情報を保存する場合、これらのユーザーがこれまでよりも簡単にファイル転送できるようになりました。 Active Directory コネクタを使用して、 AWS Managed Microsoft AD オンプレミス環境の または AWS クラウドの で Active Directory グループへのアクセスを提供できます。 AWS クラウドまたはオンプレミスネットワークのいずれかで Microsoft Windows 環境で既に設定されているユーザーに、 が ID AWS Managed Microsoft AD に使用する AWS Transfer Family サーバーへのアクセスを許可できます。 AWS ストレージブログには、Transfer Family で Active Directory を使用するためのソリューションの詳細を示す投稿が含まれています。 の[カスタム ID プロバイダーによる Active Directory 認証を簡素化します AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)。 **注記** AWS Transfer Family は Simple AD をサポートしていません。 Transfer Family はクロスリージョンの Active Directory 構成をサポートしていません。Transfer Family サーバーと同じリージョンにある Active Directory 統合のみをサポートしています。 Transfer Family は、 AWS Managed Microsoft AD または AD Connector を使用した既存の RADIUS ベースの MFA インフラストラクチャの多要素認証 (MFA) の有効化をサポートしていません。 AWS Transfer Family は、 Managed Active Directory のレプリケートされたリージョンをサポートしていません。 を使用するには AWS Managed Microsoft AD、次の手順を実行する必要があります。 1. Directory Service コンソールを使用して 1 つ以上の AWS Managed Microsoft AD ディレクトリを作成します。 1. Transfer Family コンソールを使用して、 を ID プロバイダー AWS Managed Microsoft AD として使用するサーバーを作成します。 1. Active AWS Directory Connector を使用して Directory をセットアップします。 1. 1 つ以上の Directory Service グループからのアクセスを追加します。 1. 必須ではありませんが、ユーザーアクセスのテストと検証をお勧めします。 **Topics** + [の使用を開始する前に AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq) + [Active Directoryレルムでの作業](#managed-ad-realms) + [ID プロバイダー AWS Managed Microsoft AD として を選択する](#managed-ad-identity-provider) + [オンプレミスの Microsoft Active Directory への接続](#on-prem-ad) + [グループへのアクセス権の付与](#directory-services-grant-access) + [ユーザーのテスト](#directory-services-test-user) + [グループのサーバーアクセスの削除](#directory-services-misc) + [SSH (Secure Shell) を使用してサーバーに接続する](#directory-services-ssh-procedure) + [フォレストと信頼を使用したセルフマネージド Active Directory AWS Transfer Family への接続](#directory-services-ad-trust) ## の使用を開始する前に AWS Directory Service for Microsoft Active Directory **注記** AWS Transfer Family のデフォルトの制限は、サーバーあたり 100 Active Directory グループです。ユースケースで 100 を超えるグループが必要な場合は、「 のカスタム ID プロバイダー[による Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダー AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)ソリューションの使用を検討してください。 ### AD グループに固有の識別子を提供してください。 を使用する前に AWS Managed Microsoft AD、Microsoft AD ディレクトリ内の各グループに一意の識別子を指定する必要があります。そのためには、各グループごとのセキュリティ識別子 (SID) を使用します。関連付けるグループのユーザーは、 AWS Transfer Family を使用して、有効なプロトコル経由で Amazon S3 または Amazon EFS リソースにアクセスできます。 次の Windows PowerShell コマンドを使用して *YourGroupName* を当該グループ名に置き換えることで、グループの SID を取得できます。 ``` Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid ``` **注記** ID プロバイダー AWS Directory Service として を使用し、 `userPrincipalName`と の値`SamAccountName`が異なる場合、 は の値 AWS Transfer Family を受け入れます`SamAccountName`。Transfer Family では `userPrincipalName` で指定した値は受け付けません。 ### ロールにアクセス Directory Service 許可を追加する ID プロバイダー AWS Directory Service として を使用するには、 Directory Service API アクセス許可も必要です。以下のパーミッションが必要または推奨される： + `ds:DescribeDirectories` Transfer Family がディレクトリを検索するために必要です + `ds:AuthorizeApplication` Transfer Family の承認を追加する必要があります + `ds:UnauthorizeApplication` サーバー作成プロセス中に問題が発生した場合に備えて、暫定的に作成されたリソースを削除することをお勧めします。 Transfer Family サーバーの作成に使用しているロールにこれらの権限を追加します。これらの権限の詳細については、[「Directory Service API 権限: アクション、リソース、および条件のリファレンスを参照してください」](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/UsingWithDS_IAM_ResourcePermissions.html)。 ## Active Directoryレルムでの作業 Active Directory AWS Transfer Family ユーザーにサーバーにアクセスさせる方法を検討するときは、ユーザーのレルムとそのグループのレルムに留意してください。理想的には、ユーザーのレルムとそのグループのレルムが一致している必要があります。つまり、ユーザーとグループの両方がデフォルト レルム内にあるか、両方とも信頼されたレルム内にあります そうでない場合、ユーザーは Transfer Family によって認証されません。 ユーザーをテストして、構成が正しいことを確認できます。詳細については、「[ユーザーのテスト](#directory-services-test-user)」を参照してください。ユーザー/グループ レルムに問題がある場合は、ユーザーのグループに関連付けられたアクセスが見つかりませんというエラーが表示されます。 ## ID プロバイダー AWS Managed Microsoft AD として を選択する このセクションでは、 サーバー AWS Directory Service for Microsoft Active Directory で を使用する方法について説明します。 **Transfer Family AWS Managed Microsoft AD で を使用するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/) で Directory Service コンソールを開きます。 Directory Service コンソールを使用して、1 つ以上のマネージドディレクトリを設定します。詳細については、* Directory Service 管理者ガイド*の [AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) を参照してください。 ![\[ディレクトリのリストとその詳細を表示するディレクトリ サービス コンソール。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/directory-services-AD-list.png) 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開き、**サーバーの作成**を選択します。 1. [**Choose protocols**] ( プロトコルの選択) ページのリストから 1 つ以上のプロトコルを選択します。 **注記** **FTPS** を選択した場合、 AWS Certificate Manager 証明書を提供する必要があります。 1. [**Choose an identity provider**] (ID プロバイダーを選択する) で[**AWS Directory Service**] を選択します。 ![\[Directory Service を選択した場合の [Choose identity provider] (ID プロバイダーの選択) セクションを示すコンソールの画面例。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/create-server-choose-idp-directory-services.png) 1. [**Directory**] (ディレクトリ) リストには、設定したすべてのマネージドディレクトリが含まれます。リストからディレクトリを選択し、[**Next**] (次へ) を選択します。 **注記** クロスアカウントディレクトリと共有ディレクトリはサポートされていません AWS Managed Microsoft AD。 Directory Service を ID プロバイダーとしてサーバーを設定するには、いくつかの Directory Service アクセス許可を追加する必要があります。詳細については、「[の使用を開始する前に AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)」を参照してください。 1. サーバーの作成を終了するには、以下のいずれかの手順に従います。 + [SFTP 対応サーバーの作成](create-server-sftp.md) + [FTPS 対応サーバーを作成する](create-server-ftps.md) + [FTP 対応サーバーの作成](create-server-ftp.md) これらの手順では、ID プロバイダーを選択するステップに進みます。 **重要** Transfer Family サーバーで Microsoft AD ディレクトリを使用した Directory Service 場合、 で Microsoft AD ディレクトリを削除することはできません。まずサーバーを削除してから、ディレクトリを削除する必要があります。 ## オンプレミスの Microsoft Active Directory への接続 このセクションでは、AD Connector を使用して AWS ディレクトリを設定する方法について説明します。 **AD Connector を使用して AWS ディレクトリを設定するには** 1. [[ディレクトリ サービス]](https://console.aws.amazon.com/directoryservicev2/) コンソールを開き、**[ディレクトリ]** を選択します。 1. **[Set up directory]** (ディレクトリをセットアップする) を選択します。 1. ディレクトリタイプには、**[AD Connector]** を選択します。 1. ディレクトリ サイズを選択し、**[次へ]** を選択して、VPC とサブネットを選択します。 1. **[Next]** を選択し、次のようにフィールドに入力します。 + **ディレクトリ DNS 名**: Microsoft Active Directory に使用しているドメイン名を入力します。 + **DNS IP アドレス**: Microsoft Active Directory の IP アドレスを入力します。 + **サーバーアカウントのユーザー名とパスワード******: 使用するサービスアカウントの詳細を入力します。 1. 画面に入力してディレクトリ サービスを作成します 次のステップでは、SFTP プロトコルと **AWS Directory Service** の ID プロバイダータイプを使用して Transfer Family サーバーを作成します。**ディレクトリ**ドロップダウンリストから、前の手順で追加したディレクトリを選択します。 ## グループへのアクセス権の付与 サーバーを作成したら、 を使用して有効なプロトコル経由でファイルをアップロードおよびダウンロードするためのアクセス権をディレクトリ内のどのグループに付与するかを選択する必要があります AWS Transfer Family。そのためには、*アクセス*権を作成します。 **注記** AWS Transfer Family のデフォルトの制限は、サーバーあたり 100 Active Directory グループです。ユースケースで 100 を超えるグループが必要な場合は、「 のカスタム ID プロバイダー[による Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダー AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)ソリューションの使用を検討してください。 **注記** ユーザーはアクセスを付与されたグループに*直接*属していなければなりません。たとえば、Bob がユーザーで groupA に属し、groupA 自体が groupB に含まれているとします。 GroupA へのアクセス権を付与すると、Bob にはアクセス権が付与されます。 GroupB にアクセス権を付与する (そして GroupA しない) と、Bob にはアクセス権がありません。 **グループへのアクセス権を付与するには** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。 1. サーバーの詳細ページに移動します。 1. [**アクセス**] セクションで、[**アクセスの追加**] を選択します。 1. このサーバーにアクセスする AWS Managed Microsoft AD ディレクトリの SID を入力します。 **注記** グループの SID を検索する方法については、「[の使用を開始する前に AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)」を参照してください。 1. **Access** で、グループの AWS Identity and Access Management (IAM) ロールを選択します。 1. [**Policy**] (ポリシー) セクションでポリシーを選択します。デフォルト設定は [**None**] (なし) です。 1. **ホームディレクトリ**で、グループのホームディレクトリに対応する Amazon S3 バケットを選択します。 **注記** セッションポリシーを作成して、ユーザーに表示されるバケットの部分を限定できます。たとえば、ユーザーを `/filetest` ディレクトリの下位にある各自のフォルダに限定するには、フィールドに次のテキストを入力します。 ``` /filetest/${transfer:UserName} ``` セッションポリシーの作成方法の詳細については、「[Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md)」を参照してください 。 1. [**Add**] (追加) をクリックして関連付けを作成します。 1. サーバーを選択します。 1. 「**アクセスの追加**」を選択します。 1. グループの SID を入力します。 **注記** DID を見つける方法については、「[の使用を開始する前に AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)」を参照してください。 1. 「**アクセスの追加**」を選択します。 [**Accesses**] (アクセス) セクションにサーバアクセス権が一覧表示されます。 ![\[コンソールにアクセスセクションが表示され、サーバーのアクセスが表示されています。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/accesses-list.png) ## ユーザーのテスト ユーザーがサーバーの AWS Managed Microsoft AD ディレクトリにアクセスできるかどうかをテストできます。 **注記** ユーザーは、[**Endpoint configuration**] (エンドポイント設定) ページの [**Access**] (アクセス) セクションのリストにあるいずれかのグループ (外部 ID) に属している必要があります。ユーザーがグループに属していない場合、または複数のグループに属している場合、そのユーザーにはアクセス権が付与されません。 **特定のユーザーがアクセス権を持っているかどうかをテストするには** 1. サーバーの詳細ページで [**Actions**] (アクション) を選択してから [**Test**] (テスト) を選択します。 1. [**ID プロバイダのテスト**] には、アクセス権を持つグループの 1 つに属しているユー ザーのサインイン認証情報を入力します。 1. [**Test**] (テスト) を選択します。 選択したユーザーにサーバーへのアクセスが許可されていることを示す、ID プロバイダーのテストが成功しました。 ![\[ID プロバイダーのテスト成功レスポンスのコンソール画面例。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/identity-provider-test-success.png) ユーザーがアクセス権のある複数のグループに属している場合、次のレスポンスが表示されます。 ``` "Response":"", "StatusCode":200, "Message":"More than one associated access found for user's groups." ``` ## グループのサーバーアクセスの削除 **グループのサーバーアクセスを削除するには** 1. サーバーの詳細ページで [**Actions**] (アクション) を選択してから [**Delete Access**] (アクセスの削除) を選択します。 1. ダイアログボックスで、このグループのアクセスを削除したいことを確認します。 サーバーの詳細ページに戻ると、このグループのアクセス権がリストから消えたことがわかります。 ## SSH (Secure Shell) を使用してサーバーに接続する サーバーとユーザーを設定したら、SSH を使ってサーバーに接続し、アクセス権を持つユーザーの完全修飾ユーザー名を使うことができます。 ``` sftp user@active-directory-domain@vpc-endpoint ``` 例: `transferuserexample@mycompany.com@vpce-0123456abcdef-789xyz.vpc-svc-987654zyxabc.us-east-1.vpce.amazonaws.com`。 この形式は、潜在的に大規模な Active Directory の検索を限定し、フェデレーションの検索を対象とします。 **注記** 単純なユーザー名を指定することができます。ただし、この場合、Active Directory コードはフェデレーション内のすべてのディレクトリを検索する必要があります。そうすると検索が限定され、ユーザーにアクセス権があっても認証が失敗する可能性があります。 認証後、ユーザーは、ユーザーの設定時に指定されたホームディレクトリ内にいます。 ## フォレストと信頼を使用したセルフマネージド Active Directory AWS Transfer Family への接続 Directory Service には、セルフマネージド Active Directory に接続するための以下のオプションがあります。 + 一方向フォレスト信頼 (オンプレミス Active Directory の送受信) は AWS Managed Microsoft AD 、ルートドメインに対してのみ機能します。 + 子ドメインの場合、以下のいずれかを使用できます: + AWS Managed Microsoft AD とオンプレミス Active Directory 間の双方向信頼を使用する + 各子ドメインに対して一方向の外部信頼を使用します。 信頼できるドメインを使用してサーバーに接続する場合、ユーザーは信頼できるドメインを指定する必要があります (例: `transferuserexample@mycompany.com`)。 # AWS Directory Service for Entra ID ドメインサービスの使用 SFTP 転送のみが必要で、ドメインの管理を希望しないお客様には、Simple Active Directory があります。あるいは、Active Directory の利点と高可用性を完全に管理されたサービスで利用したいお客様は、Managed Microsoft AD AWS を使用できます。最後に、既存の Active Directory フォレストを SFTP Transfer に活用したいお客様には、Active Directory Connector があります。 次の点に注意してください。 + SFTP 転送のニーズに合わせて既存の Active Directory フォレストを利用するには、[Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) を使用できます。 + フルマネージド サービスで Active Directory と高可用性のメリットを享受したい場合は、 AWS Directory Service for Microsoft Active Directoryを使用できます。詳細については、「[AWS Directory Service for Microsoft Active Directory の使用](directory-services-users.md)」を参照してください。 このトピックでは、Active Directory Connector と [Entra ID (以前の Azure AD) ドメインサービス](https://azure.microsoft.com/en-us/services/active-directory-ds/)を使用して、Entra ID で SFTP Transfer ユーザーを認証する方法について説明します。 **Topics** + [AWS Directory Service for Entra ID ドメインサービスの使用を開始する前に](#azure-prereq) + [ステップ 1: Entra ID ドメインサービスを追加する](#azure-add-adds) + [ステップ 2：サービスアカウントの作成](#azure-create-service-acct) + [ステップ 3: AD Connector を使用して AWS ディレクトリをセットアップする](#azure-setup-directory) + [ステップ 4: AWS Transfer Family サーバーをセットアップする](#azure-setup-transfer-server) + [ステップ5：グループへのアクセス権の付与](#azure-grant-access) + [ステップ 6: ユーザーのテスト](#azure-test) ## AWS Directory Service for Entra ID ドメインサービスの使用を開始する前に **注記** AWS Transfer Family のデフォルトの制限は、サーバーあたり 100 Active Directory グループです。ユースケースで 100 を超えるグループが必要な場合は、「 のカスタム ID プロバイダー[を使用した Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダー AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)ソリューションの使用を検討してください。 には AWS、以下が必要です。 + Transfer Family サーバーを使用している AWS リージョンの Virtual Private Cloud (VPC) + VPC 内に少なくとも 2 つのプライベート サブネット + VPC はインターネットに接続していなければならない。 + Microsoft Entra とのsite-to-site接続用のカスタマーゲートウェイと仮想プライベートゲートウェイ Microsoft Entra の場合、以下が必要です。 + Entra ID と Active Directory ドメインサービス + Entra リソースグループ + Entra 仮想ネットワーク + Amazon VPC と Entra リソースグループ間の VPN 接続 **注記** これは、ネイティブ IPSEC トンネル経由、または VPN アプライアンスを使用して行うことができます。このトピックでは、Entra Virtual Network Gateway とローカルネットワークゲートウェイ間の IPSEC トンネルを使用します。トンネルは、Entra Domain Service エンドポイントと AWS VPC を格納するサブネット間のトラフィックを許可するように設定する必要があります。 + Microsoft Entra とのsite-to-site接続用のカスタマーゲートウェイと仮想プライベートゲートウェイ 次の図は、開始する前に必要な構成を示しています。 ![\[Entra/Azure AD と AWS Transfer Family アーキテクチャ図。 AWS Directory Service コネクタを使用して Entra Domain Service にインターネット経由で Entra 仮想ネットワークに接続する AWS VPC。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-architecture.png) ## ステップ 1: Entra ID ドメインサービスを追加する Entra ID は、デフォルトではドメイン結合インスタンスをサポートしていません。ドメイン結合などのアクションを実行し、グループポリシーなどのツールを使用するには、管理者は Entra ID ドメインサービスを有効にする必要があります。Entra DS をまだ追加していない場合、または既存の実装が SFTP Transfer Server で使用するドメインに関連付けられていない場合は、新しいインスタンスを追加する必要があります。 Entra ID ドメインサービスを有効にする方法については、[「チュートリアル: Microsoft Entra Domain Services マネージドドメインの作成と設定](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started)」を参照してください。 **注記** Entra DS を有効にするときは、SFTP Transfer Server を接続する先のリソースグループと Entra ドメイン用に設定されていることを確認します。 ![\[bob.us が実行されているリソースグループを示す Entra ドメインサービス画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-ad-add-instance.png) ## ステップ 2：サービスアカウントの作成 Entra には、Entra DS の管理者グループの一部であるサービスアカウントが 1 つ必要です。このアカウントは AWS Active Directory コネクタで使用されます。このアカウントが Entra DS と同期していることを確認します。 ![\[ユーザーのプロファイルを示す Entra 画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-service-acct.png) **ヒント** Entra ID の多要素認証は、SFTP プロトコルを使用する Transfer Family サーバーではサポートされていません。Transfer Family サーバーは、ユーザーが SFTP に対して認証された後、MFA トークンを提供できません。接続を試行する前に、必ず MFA を無効にしてください。 ![\[2 人のユーザーに対して MFA ステータスが無効になっていることを示すエントラ多要素認証の詳細。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-ad-mfa-disable.png) ## ステップ 3: AD Connector を使用して AWS ディレクトリをセットアップする Entra DS を設定し、 AWS VPC と Entra Virtual Network の間に IPSEC VPN トンネルを持つサービスアカウントを作成したら、任意の AWS EC2 インスタンスから Entra DS DNS IP アドレスに ping を送信して接続をテストできます。 接続がアクティブであることを確認したら、以下に進むことができます。 **AD Connector を使用して AWS ディレクトリを設定するには** 1. [[ディレクトリ サービス]](https://console.aws.amazon.com/directoryservicev2/) コンソールを開き、**[ディレクトリ]** を選択します。 1. **[Set up directory]** (ディレクトリをセットアップする) を選択します。 1. ディレクトリタイプには、**[AD Connector]** を選択します。 1. ディレクトリ サイズを選択し、**[次へ]** を選択して、VPC とサブネットを選択します。 1. **[Next]** を選択し、次のようにフィールドに入力します。 + **ディレクトリ DNS 名**: Entra DS に使用しているドメイン名を入力します。 + **DNS IP アドレス**: Entra DS IP アドレスを入力します。 + **[サーバー アカウントのユーザー名]** **[とパスワード]**: ステップ 2: サービス アカウントを作成するで作成したサービス アカウントの詳細を入力します。 1. 画面に入力してディレクトリ サービスを作成します これで、ディレクトリのステータスが**[アクティブ] **になり、SFTP 転送サーバーで使用する準備が整いました。 ![\[必要に応じて、ステータスが Active のディレクトリが 1 つ表示される Directory Services 画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-connector-ready.png) ## ステップ 4: AWS Transfer Family サーバーをセットアップする SFTP プロトコルと **AWS Directory Service** の ID プロバイダータイプを使用して Transfer Family サーバーを作成します。**[ディレクトリ]** ドロップダウン リストから、ステップ 3: AD コネクタ AWS を使用してディレクトリを設定するで追加したディレクトリを選択します。 **注記** Transfer Family サーバーで使用した場合、 AWS Directory Service で Microsoft AD ディレクトリを削除することはできません。まずサーバーを削除してから、ディレクトリを削除する必要があります。 ## ステップ5：グループへのアクセス権の付与 サーバーを作成したら、 を使用して有効なプロトコル経由でファイルをアップロードおよびダウンロードするためのアクセス権をディレクトリ内のどのグループに付与するかを選択する必要があります AWS Transfer Family。そのためには、*アクセス*権を作成します。 **注記** ユーザーはアクセスを付与されたグループに*直接*属していなければなりません。たとえば、Bob がユーザーで groupA に属し、groupA 自体が groupB に含まれているとします。 GroupA へのアクセス権を付与すると、Bob にはアクセス権が付与されます。 GroupB にアクセス権を付与する (そして GroupA しない) と、Bob にはアクセス権がありません。 アクセスを許可するには、グループの SID を取得する必要があります。 次の Windows PowerShell コマンドを使用して *YourGroupName* を当該グループ名に置き換えることで、グループの SID を取得できます。 ``` Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid ``` ![\[取得中のオブジェクト SID を示す Windows PowerShell。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-grant-access.png) **グループへのアクセスを許可する** 1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) を開きます。 1. サーバーの詳細ページに移動し、[**アクセス**] セクションで**[アクセスの追加**] を選択します。 1. 前の手順の出力から受け取った SID を入力してください。 1. **Access** で、グループの AWS Identity and Access Management ロールを選択します。 1. [**Policy**] (ポリシー) セクションでポリシーを選択します。デフォルト値は [**なし**] です。 1. **ホームディレクトリ**で、グループのホームディレクトリに対応する Amazon S3 バケットを選択します。 1. [**Add**] (追加) をクリックして関連付けを作成します。 Transfer サーバーの詳細は、次のように見えるべきです: ![\[Transfer Family サーバーの詳細画面の一部。ID プロバイダーのディレクトリ ID の例を示します。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-assoc-1.png) ![\[Transfer Family サーバーの詳細画面の一部。画面のアクセス部分にアクティブディレクトリの外部 ID が表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/azure-assoc-2.png) ## ステップ 6: ユーザーのテスト ユーザーがサーバーの AWS Managed Microsoft AD ディレクトリにアクセスできるかどうかをテスト（[ユーザーのテスト](directory-services-users.md#directory-services-test-user)）できます。ユーザーは、[**Endpoint configuration**] (エンドポイント設定) ページの [**Access**] (アクセス) セクションのリストにあるいずれかのグループ (外部 ID) に属している必要があります。ユーザーがグループに属していない場合、または複数のグループに属している場合、そのユーザーにはアクセス権が付与されません。