カスタム ID プロバイダーの使用 - AWS Transfer Family

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

カスタム ID プロバイダーの使用

ユーザーを認証するには、AWS Transfer Family で既存の ID プロバイダーを使用します。ID プロバイダーを統合するには、AWS Lambda 関数を使用して、Amazon S3 または Amazon Elastic File System (Amazon EFS) へのアクセス権を認証および承認します。詳細については、「AWS Lambda の使用による ID プロバイダーの統合」を参照してください。アクセスすることもできます CloudWatch で転送されたファイル数やバイト数などのメトリックのグラフAWS Transfer Family管理コンソール。一元化されたダッシュボードを使用してファイル転送を一元的に監視できます。

または、単一の Amazon API Gateway メソッドで RESTful インターフェイスを提供することもできます。Transfer Family は、このメソッドを呼び出して ID プロバイダーに接続し、ID プロバイダーは Amazon S3 または Amazon EFS へのアクセスを認証および承認します。このオプションを使用するのは、ID プロバイダーの統合に RESTful API が必要な場合、または AWS WAF を使用して geo-blocking もしくは rate-limiting リクエストにその機能を利用したい場合です。詳細については、「Amazon API Gateway を使用して ID プロバイダーを統合する」を参照してください。

いずれの場合も、を使用して新しいサーバーを作成できます。AWS Transfer FamilyコンソールまたはCreateServerAPI オペレーション。

AWS Lambda の使用による ID プロバイダーの統合

カスタム ID プロバイダーに接続する AWS Lambda 関数を作成します。Okta、Secrets Manager、 OneLogin、または承認ロジックを含むカスタムデータストア。

注記

Lambda を ID プロバイダーとして使用する Transfer Family サーバーを作成する前に、関数を作成する必要があります。サンプルの Lambda 関数については、「デフォルトの Lambda 関数」を参照してください。または、デプロイすることもできます CloudFormation Aを使用するスタックLambda 関数テンプレート。また、Lambda 関数が Transfer Family と信頼関係にあるリソースベースのポリシーを使用していることを確認してください。ポリシーの例については、「Lambda リソースベースのポリシー」を参照してください。

  1. AWS Transfer Family コンソールを開きます。

  2. [Create server] (サーバーの作成) を選択すると [Create server] (サーバーの作成) ページが開きます。[Choose an identity provider] (ID プロバイダーの選択) で [Custom Identity Provider] (カスタム ID プロバイダー) を選択します (次の画面例を参照)。

  3. デフォルト値である [Use AWS Lambda to connect your identity provider] (を使用して ID プロバイダーに接続する) が選択されていることを確認します。

  4. [AWS Lambda function] (関数) に Lambda 関数の名前を入力します。

  5. 残りのフィールドに値を入力してから [Create server] (サーバーの作成) を選択します。サーバーを作成するための残りの手順の詳細については、「サーバーの作成」を参照してください。

Lambda リソースベースのポリシー

Transfer Family サーバーと Lambda ARN を参照するポリシーが必要です。たとえば、ID プロバイダーに接続する Lambda 関数で次のポリシーを使用できます。

{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "AllowTransferInvocation", "Effect": "Allow", "Principal": { "Service": "transfer.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "$lambda_arn", "Condition": { "ArnLike": { "AWS:SourceArn": "$server_arn" } } } ] }

イベントメッセージの構造

SFTP サーバーからカスタム IDP のオーソライザー Lambda 関数に送信されるイベントメッセージ構造は次のとおりです。

{ 'username': 'value', 'password': 'value', 'protocol': 'SFTP', 'serverId': 's-abcd123456', 'sourceIp': '192.168.0.100' }

WHERusernameそして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 で似ています。唯一の違いは、これらの値がprotocolSFTPではなくパラメータ。

認証用の Lambda 関数

さまざまな認証戦略を実装するには、Lambda 関数を編集します。アプリケーションのニーズを満たすために、 CloudFormation スタック。Lambda の詳細については、AWS Lambda デベロッパーガイドまたは「Node.js による Lambda 関数の構築」を参照してください。

Lambda 関数テンプレート

Lambda 関数を認証に使用する AWS CloudFormation スタックをデプロイできます。ユーザー名とパスワードでユーザーを認証して承認するためのテンプレートがいくつか用意されています。これらのテンプレートを変更するかAWS Lambdaユーザーアクセスをさらにカスタマイズするためのコード。

認証に使用する AWS CloudFormation スタックを作成するには

  1. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソール を開きます。

  2. AWS CloudFormation ユーザーガイドの「スタックテンプレートの選択」に従って既存のテンプレートから AWS CloudFormation スタックをデプロイしてください。

  3. Transfer Family で認証に使用する Lambda 関数を作成するには、次のいずれかのテンプレートを使用します。

    重要

    デフォルトのユーザーとパスワード認証情報を編集することをお勧めします。

    • クラシック (Cognito) スタックテンプレート

      を作成するための基本的なテンプレートAWS Lambdaでカスタム ID プロバイダーとして使用できますAWS Transfer Family。パスワードベースの認証では cognito に対して認証を行い、パブリックキーベースの認証が使用されている場合、パブリックキーは Amazon S3 バケットから返されます。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。

    • AWS Secrets Manager スタックテンプレート

      を使用する基本的なテンプレートAWS LambdaとAWS Transfer FamilySecrets Manager をアイデンティティプロバイダーとして統合するサーバー。のエントリに対して認証しますAWS Secrets Managerの形式で設定SFTP/username。さらに、シークレットは、Transfer Family に返されるすべてのユーザープロパティのキーバリューペアを保持する必要があります。デプロイ後に Lambda 関数コードを変更すれば異なる処理を実行できます。

    • Okta スタックテンプレート: を使用する基本的なテンプレートAWS LambdaとAWS Transfer FamilyOkta をカスタム ID プロバイダーとして統合するためのサーバー。

    • Okta-MFA スタックテンプレート: を使用する基本的なテンプレートAWS LambdaとAWS Transfer FamilyOktaを統合するサーバー、 MultiFactor カスタム ID プロバイダーとしての認証。

    スタックのデプロイ後には、出力のタブ CloudFormation コンソール。

    これらのスタックのいずれかをデプロイすることが、カスタム ID プロバイダーをTransfer Family ワークフローに統合するうえで最も簡単な方法です。デフォルトでは、Lambda 関数は、myuser という単一のユーザーを MySuperSecretPassword のパスワードで認証します。デプロイ後に、これらの認証情報を編集するか Lambda 関数コードを更新すれば異なる処理を実行できます。

有効な Lambda 値

次の表は、カスタム ID プロバイダーに使用される Lambda 関数について Transfer Family が受け入れる値の詳細についての説明です。

説明 必須

Role

Amazon S3 バケットまたは Amazon EFS ファイルシステムへのユーザーのアクセスを制御する IAM ロールの Amazon Resource Name (ARN) を指定します。このロールにアタッチされたポリシーにより、ファイルを Amazon S3 または Amazon EFS ファイルシステム間で転送する際のユーザーに付与するアクセスのレベルが決定されます。IAM ロールには、ユーザーの転送リクエストを処理する際に、サーバーによるリソースへのアクセスを許可する信頼関係も含まれる必要があります。

必須

PosixProfile

ユーザーの Amazon EFS ファイルシステムへのアクセスを制御する、ユーザー ID (Uid)、グループ ID (Gid)、およびセカンダリグループ ID (SecondaryGids) を含む完全な POSIX ID。ファイルシステム内のファイルとディレクトリに設定される POSIX アクセス許可によって、Amazon EFS ファイルシステムとの間でファイルを転送するときにユーザーが得るアクセスのレベルが決まります。

Amazon EFS バッキングストレージに必須

PublicKeys

このユーザーに有効な SSH パブリックキー値のリスト。空のリストはこれが有効なログインではないことを示します。パスワード認証中に返してはなりません。

任意

Policy

複数のユーザーに同じ IAM ロールの使用を可能にするユーザーのセッションポリシー。このポリシーは、ユーザーアクセスのスコープを Amazon S3 バケットの一部に絞り込みます。

任意

HomeDirectoryType

ユーザーがサーバーにログインするときにホームディレクトリにするランディングディレクトリ (フォルダ) のタイプ。PATH に設定した場合、ユーザーにはファイル転送プロトコルクライアント内の Amazon S3 バケットまたは Amazon EFS の絶対パスが表示されます。これを LOGICAL に設定した場合、Amazon S3 または Amazon EFS パスをユーザーに表示する方法について、HomeDirectoryMappings パラメータでマッピングを指定する必要があります。

任意

HomeDirectoryDetails

ユーザーに表示する Amazon S3 または Amazon EFS のパスとキー、およびそれらをどのように表示するかを指定する論理ディレクトリマッピング。「Entry」と「Target」のペアを指定する必要があり、Entry はパスの表示方法を示し、Target は実際の Amazon S3 または Amazon EFS のパスです。

HomeDirectoryTypeLOGICAL の値がある場合に必須

HomeDirectory

ユーザーがクライアントを使用してサーバーにログインするときの、ユーザーのランディングディレクトリ。

任意

設定をテストする

カスタム ID プロバイダーを作成したら、設定をテストする必要があります。

Console

AWS Transfer Family コンソールを使用して設定をテストするには

  1. AWS Transfer Family コンソールを開きます。

  2. [Servers] (サーバー) ページで新しいサーバーを選択し、[Actions] (アクション) を選択してから [Test] (テスト) を選択します。

  3. AWS CloudFormation スタックをデプロイする際に設定した [Username] (ユーザー名) と [Password] (パスワード) を入力します。デフォルトのオプションを受け入れた場合、ユーザー名は myuser、パスワードは MySuperSecretPassword です。

  4. [Server protocol] (サーバープロトコル) を選択し、AWS CloudFormation スタックのデプロイ時に送信元 IP アドレスを設定した場合には [Source IP] にアドレスを入力します。

CLI

AWS CLI を使用して設定をテストするには

  1. test-identity-provider コマンドを実行します。以降のステップで説明するように、それぞれの 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
  2. サーバー ID を入力します。

  3. AWS CloudFormation スタックをデプロイする際に設定したユーザー名とパスワードを入力します。デフォルトのオプションを受け入れた場合、ユーザー名は myuser、パスワードは MySuperSecretPassword です。

  4. サーバープロトコルを指定し、AWS CloudFormation スタックのデプロイ時に送信元 IP アドレスを設定した場合にはそれを入力します。

ユーザー認証が成功すると、テストはStatusCode: 200HTTP レスポンスと、次の例に示すように、ユーザーのロールと権限の詳細を含む JSON オブジェクト。

{ "Response": "{\"Policy\": \"{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n{\n \"Sid\": \"ReadAndListAllBuckets\",\n \"Effect\": \"Allow\",\n \"Action\": [\n \"s3:ListAllMybuckets\",\n \"s3:GetBucketLocation\",\n \"s3:ListBucket\",\n \"s3:GetObjectVersion\",\n \"s3:GetObjectVersion\"\n],\n \"Resource\":\"*\"\n}\n]\n}\",\"Role\": \"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\": \"/\"}", "StatusCode": 200, "Message": "", "Url": "https://abcde1234.execute-api.us-east-2.amazonaws.com/prod/servers/s-123a4567bcd891e23/users/myuser/config" }
注記

"Url": の行は、カスタム ID プロバイダーとして API Gateway メソッドを使用している場合にのみ返されます。

Amazon API Gateway を使用して ID プロバイダーを統合する

このセクションでは、API Gateway メソッドを支える AWS Lambda 関数の使用方法を説明します。このオプションを使用するのは、ID プロバイダーの統合に RESTful API が必要な場合、または AWS WAF を使用して geo-blocking もしくは rate-limiting リクエストにその機能を利用したい場合です。

API Gateway を使用して ID プロバイダーを統合する場合の制限

  • この構成はカスタムドメインをサポートしていません。

  • この構成では、プライベート API Gateway URL はサポートされていません。

これらのいずれかが必要な場合は、API Gateway なしで Lambda を ID プロバイダーとして使用できます。詳細については、「AWS Lambda の使用による ID プロバイダーの統合」を参照してください。

API Gateway メソッドを使用した認証

Transfer Family の ID プロバイダーとして使用する API Gateway メソッドを作成できます。このアプローチは、API を作成して提供するための非常に安全な方法です。API Gateway では、HTTPS エンドポイントを作成して、すべての着信 API コールをより高いセキュリティで送信できます。API Gateway サービスの詳細については、API Gateway デベロッパーガイドを参照してください。

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 リクエストのモニタリングが可能です。詳細については、「ウェブアプリケーションファイアウォールを追加する」を参照してください

Transfer Family でカスタム認証に API Gateway メソッドを使用するには

  1. AWS CloudFormation スタックを作成します。そのためには、以下の操作をします。

    1. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソール を開きます。

    2. AWS CloudFormation ユーザーガイドの「スタックテンプレートの選択」に従って既存のテンプレートから AWS CloudFormation スタックをデプロイしてください。

    3. 次の基本テンプレートのいずれかを使用して、Transfer Family でカスタム ID プロバイダーとして使用する AWS Lambda Backed API Gateway メソッドを作成します。

    これらのスタックのいずれかをデプロイすることが、カスタム ID プロバイダーをTransfer Family ワークフローに統合するうえで最も簡単な方法です。各スタックは Lambda 関数を使用して、API Gateway に基づく API メソッドをサポートします。その後、Transfer Family でカスタム ID プロバイダーとして API メソッドを使用できます。デフォルトでは、Lambda 関数は、myuser という単一のユーザーを MySuperSecretPassword のパスワードで認証します。デプロイ後に、これらの認証情報を編集するか Lambda 関数コードを更新すれば異なる処理を実行できます。

    重要

    デフォルトのユーザーとパスワード認証情報を編集することをお勧めします。

    スタックのデプロイ後には、出力のタブ CloudFormation コンソール。具体的には、スタックの Amazon リソースネーム (ARN)、スタックが作成した IAM ロールの ARN、および新しいゲートウェイの URL が含まれます。

    注記

    カスタム ID プロバイダーオプションを使用してユーザーのパスワードベースの認証を有効にし、API Gateway によって提供されるリクエストとレスポンスのログを有効にした場合、API Gateway はユーザーのパスワードを Amazon に記録します。 CloudWatch ログ。本稼働環境でこのログを使用することは推奨されません。詳細については、次を参照してください。セットアップ CloudWatch API Gateway で API ログイン()API Gateway 開発者ガイド

  2. サーバーの API Gateway メソッドの設定を確認します。これを実行するには:

    1. API Gateway コンソール (https://console.aws.amazon.com/apigateway) を開きます。

    2. AWS CloudFormation で生成された [Transfer Custom Identity Provider basic template API] (カスタム ID プロバイダーの基本テンプレート API を転送する) を選択します。

      次の画面例は、完全な API 設定を示しています。この例では、メソッドは Lambda 関数に支えられますが、他の数多くの統合タイプも可能です。

    3. [Resource] (リソース) ペインで GET を選択してから [Method Request] (メソッドの作成) を選択します。次の画面例は、正しいメソッド設定を示しています。

    この時点で、API Gateway をデプロイする準備が整いました。

  3. [Actions] (アクション) で [Deploy API] (API のデプロイ) を選択します。[Deplyment stage] (デプロイステージ) で prod を選択してから [Deploy] (デプロイ) を選択します。

    API Gateway メソッドが正常にデプロイされると、[Stage Editor] (ステージエディタ) セクションにそのパフォーマンスが表示されます (次の画面例を参照)。

    注記

    画面の最上部に表示される [Invoke URL] (呼び出し URL) アドレスをコピーします。次のステップで必要になります。

  4. https://console.aws.amazon.com/transfer/ で AWS Transfer Family コンソールを開きます。

  5. [Create server] (サーバーの作成) を選択すると [Create server] (サーバーの作成) ページが開きます。[Choose an identity provider] (ID プロバイダーの選択) で [Custom] (カスタム) を選択してから、[Use Amazon API Gateway to connect to your identity provider] (Amazon API Gateway を使用してアイデンティティプロバイダーに接続する) を選択します (次の画面例を参照)。

  6. [Provide an Amazon API Gateway URL] (Amazon API Gateway URL を指定) テキストボックスに、ステップ 3 で作成した API Gateway エンドポイントの [Invoke URL] (呼び出し URL) アドレスを貼り付けます。

  7. [Role] (ロール) について、AWS CloudFormation テンプレートで作成した IAM ロールを選択します。このロールにより、Transfer Family が API Gateway メソッドを呼び出せるようになります。

    呼び出しロールには、ステップ 1 で作成したスタックに付けた AWS CloudFormation スタック名が含まれています。次のような形式です: CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI

  8. 残りのフィールドに値を入力してから [Create server] (サーバーの作成) を選択します。サーバーを作成するための残りの手順の詳細については、「サーバーの作成」を参照してください。

API Gateway メソッドを実装する

Transfer Family のカスタム ID プロバイダーを作成するには、API Gateway メソッドで/servers/serverId/users/username/config のリソースパスを持つ単一のメソッドを実装する必要があります。serverIdusername の値は RESTful リソースパスから取得されます。また、追加してくださいsourceIpそしてprotocolなので[URL クエリ文字列パラメータ]()メソッドリクエスト、次の図に示すように。

注記

ユーザー名は、最小 3 文字、最大 100 文字にする必要があります。ユーザー名に使用できる文字は、z、A~Z、0~9、下線文字 (_)、ハイフン (-)、ピリオド (.)、およびアットマーク (@) です。ただし、ユーザー名をハイフン (-)、ピリオド (.)、またはアットマーク (@) で始めることはできません。

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": "/bucketName/path/to/home/directory" }
注記

ポリシーは、JSON で文字列としてエスケープされます。例:

"Policy": "{ \"Version\": \"2012-10-17\", \"Statement\": [ {\"Condition\": {\"StringLike\": {\"s3:prefix\": [\"user/*\", \"user/\"]}}, \"Resource\": \"arn:aws:s3:::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/role-api-gateway-s3\", \"HomeDirectoryType\":\"LOGICAL\", \"HomeDirectoryDetails\":\"[{\\\"Entry\\\":\\\"/\\\",\\\"Target\\\":\\\"/my-home-bucket\\\"}]\", \"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/role-api-gateway-efs\", \"HomeDirectoryType\": \"LOGICAL\", \"HomeDirectoryDetails\":\"[{\\\"Entry\\\":\\\"/\\\",\\\"Target\\\":\\\"/faa1a123\\\"}]\", \"PublicKeys\":[\"\"], \"PosixProfile\":{\"Uid\":65534,\"Gid\":65534} }

Lambda 関数にユーザーポリシーを JSON 形式で含めることができます。Transfer Family でのユーザーポリシーの設定の詳細については、「アクセスコントロールの管理」を参照してください。

デフォルトの Lambda 関数

異なる認証戦略を実装するには、ゲートウェイで使用する Lambda 関数を編集します。アプリケーションのニーズを満たすために、Node.js 内で次の Lambda 関数の例を使用できます。Lambda の詳細については、AWS Lambda デベロッパーガイドまたは「Node.js による Lambda 関数の構築」を参照してください。

次の 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 を使用しているワークロードは引き続き安全だからです。

このサンプル関数は Amazon S3 でのみ機能します。この関数の例は、ロールと論理ホームディレクトリの詳細、ならびに (公開鍵認証を実行する場合には) パブリックキーを返します。

-HomeDirectoryTypeパラメータは、ユーザーがサーバーにログインするときにホームディレクトリにするランディングディレクトリ (フォルダ) のタイプを指定します。このパラメータを PATH に設定した場合、ユーザーにはファイル転送プロトコルクライアント内の Amazon S3 バケットまたは Amazon EFS の絶対パスが表示されます。このパラメータを、に設定した場合LOGICAL、マッピングはHomeDirectoryMappingsAmazon S3 または Amazon EFS のパスをユーザーに表示する方法について、パラメータ。

PATH home directory

この関数は、HomeDirectoryTypePATH を使用しているユーザー向けです。

// GetUserConfig Lambda exports.handler = (event, context, callback) => { console.log("Username:", event.username, "ServerId: ", event.serverId); var response; // Check if the user name presented for authentication is correct. This doesn't check the value of the serverId, 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 == '${UserName}') { response = { Role: '${UserRoleArn}', // The user will be authenticated if and only if the Role field is not blank Policy: '', // Optional JSON blob to further restrict this user's permissions HomeDirectory: '${UserHomeDirectory}' // Not required, defaults to '/' }; // Check if password is provided if (event.password == "") { // If no password provided, return the user's SSH public key response['PublicKeys'] = [ "${UserPublicKey1}" ]; // Check if password is correct } else if (event.password !== '${UserPassword}') { // 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

次の Lambda 関数は、論理ホームディレクトリを持つユーザーの詳細を提供します。この関数のユーザー、ロール、POSIX プロファイル、パスワード、およびホームディレクトリの詳細はすべて例であり、実際の値に置き換える必要があります。

// 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 serverId, only that it is provided. if (event.serverId !== "" && event.username == 'example-user') { response = { Role: 'arn:aws:iam::123456789012:role/role-api-gateway', // The user will be authenticated if and only if the Role field is not blank PosixProfile: {"Gid": 65534, "Uid": 65534}, HomeDirectoryDetails: "[{\"Entry\": \"/\", \"Target\": \"/fs-faa1a123\"}]", HomeDirectoryType: "LOGICAL", //HomeDirectory: '/fs-faa1a123' // Not required, defaults to '/' }; // Check if password is provided if (event.password == "") { // If no password provided, return the user's SSH public key response['PublicKeys'] = [ "" ]; // 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); };

AWS Secrets Manager で使用するための Lambda 関数

AWS Secrets Manager を ID プロバイダーとして使用するには、サンプルの Lambda 関数を AWS CloudFormation テンプレートとして使用します。Lambda 関数は、認証情報を使用して Secrets Manager サービスにクエリを実行し、成功すると指定されたシークレットを返します。Secrets Manager の詳細については、AWS Secrets Manager ユーザーガイドを参照してください。

この Lambda 関数を使用するサンプル AWS CloudFormation テンプレートをダウンロードするには、AWS Transfer Family よって提供される Amazon S3 バケットに移動します。