

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

# ID プロバイダー設定の編集
<a name="configuring-servers-edit-custom-idp"></a>

サーバーの ID プロバイダータイプは、任意のタイプから他のタイプに変更できます。使用可能な ID プロバイダーのタイプは次のとおりです。
+ **サービスマネージド** – ユーザー認証情報をサービス内に保存します。
+ **AWS Directory Service** – AWS Managed Microsoft AD または AWS Directory Service for Entra ID ドメインサービスを使用する
+ **カスタム** – Lambda 関数または Amazon API Gateway を使用して既存の ID プロバイダーと統合する

ID プロバイダーのタイプを変更する場合は、移行に応じて特定の情報を提供する必要があります。以下のセクションでは、変更のタイプごとに必要な情報について説明します。

**重要**  
ID プロバイダーを変更する際の考慮事項:  
**ユーザー移行** – ID プロバイダータイプを変更しても、既存のユーザー設定は自動的に移行されません。新しい ID プロバイダーシステムでユーザーを設定する必要があります。
**テスト** – 本番環境に変更を加える前に、新しい ID プロバイダー設定を徹底的にテストします。
アクセス**許可** – 変更を行う前に、新しい ID プロバイダーに必要な IAM アクセス許可とロールが設定されていることを確認します。

## サービスマネージド ID プロバイダーへの変更
<a name="change-to-service-managed"></a>

他の ID プロバイダータイプからサービスマネージドに変更する場合は、以下を行う必要があります。
+ ID プロバイダータイプとして**管理されるサービス**を選択する
+ 他の ID プロバイダーからの既存のユーザー設定は転送されないため、変更の完了 AWS Transfer Family 後に で直接新しいユーザーを作成する

例: カスタム ID プロバイダーからサービスマネージドに変更する場合は、サービス内のすべての AWS Transfer Family ユーザーアカウントと関連するアクセス許可を再作成する必要があります。

## AWS Directory Service への変更
<a name="change-to-directory-service"></a>

他の ID プロバイダータイプから AWS Directory Service に変更する場合は、以下を指定する必要があります。
+ **ディレクトリ** – 既存の AWS Managed Microsoft AD または AWS Directory Service for Entra ID ドメインサービスディレクトリを選択します。
+ **アクセス** — 特定のグループへのアクセスを制限するか、ディレクトリ内のすべてのユーザーへのアクセスを許可するかを選択します。
+ **アクセスロール** – ディレクトリへのアクセスを に許可 AWS Transfer Family する IAM ロール

例: サービスマネージド型から AWS Directory Service に変更する場合は、既存の`d-1234567890`ディレクトリを選択し、`TransferUsers`グループへのアクセスを制限して、IAM `TransferDirectoryAccessRole` ロールを指定します。

## カスタム ID プロバイダーへの変更
<a name="change-to-custom-idp"></a>

他の ID プロバイダータイプからカスタム ID プロバイダーに変更する場合は、Lambda 関数または Amazon API Gateway のいずれかを選択し、必要な設定を指定する必要があります。

### Lambda 関数の使用
<a name="change-to-lambda-idp"></a>

Lambda 関数統合の場合、以下を指定します。
+ **関数** – 認証を処理する既存の Lambda 関数を選択します。
+ **認証方法** (SFTP プロトコルの場合) — パスワード、パブリックキー、またはその両方を選択します。

例: AWS Directory Service からカスタム Lambda ID プロバイダーに変更する場合は、`TransferCustomAuth`関数を選択し、認証方法として**パスワード**を選択します。

![\[Lambda ID プロバイダーの場合、基になる Lambda 関数を変更できます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-server-idp-lambda.png)


### Amazon API Gateway の使用
<a name="change-to-api-gateway-idp"></a>

Amazon API Gateway 統合の場合、以下を指定します。
+ **API Gateway URL** – API Gateway エンドポイントの呼び出し URL
+ **呼び出しロール** – API Gateway の呼び出し AWS Transfer Family を に許可する IAM ロール
+ **認証方法** (SFTP プロトコルの場合) — パスワード、パブリックキー、またはその両方を選択します。

例: サービスマネージド型から API Gateway に変更する場合は、URL を指定し`https://abcdef123.execute-api.us-east-1.amazonaws.com/prod`、IAM `TransferApiGatewayInvocationRole` ロールを指定して、認証方法として**パブリックキー**を選択します。

![\[API ゲートウェイ ID プロバイダの場合、ゲートウェイ URL または呼び出しロール、あるいはその両方を更新できます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-server-idp-apigateway.png)


### Amazon API Gateway から Lambda 関数への変更
<a name="change-api-gateway-to-lambda"></a>

カスタム ID プロバイダー統合の一般的な移行は、Amazon API Gateway から Lambda 関数に変更されています。この変更により、同じ認証ロジックを維持しながらアーキテクチャを簡素化できます。

この移行の主な考慮事項:
+ **同じ関数、異なるアクセス許可** – API Gateway と直接 Lambda 統合の両方に同じ Lambda 関数を使用できますが、リソースポリシーを更新する必要があります。
+ **リソースポリシーの要件** – を Lambda 統合に直接変更する場合、関数のリソースポリシーは、 に加えて関数を呼び出す`transfer.amazonaws.com`アクセス許可を付与する必要があります`apigateway.amazonaws.com`。

**この変更を行うには**

1. が関数`transfer.amazonaws.com`を呼び出すことができるように Lambda 関数のリソースポリシーを更新します。

1.  AWS Transfer Family コンソールで、ID プロバイダーを API Gateway から Lambda 関数に変更します。

1. 既存の Lambda 関数を選択します。

1. 設定をテストして、認証が正しく機能することを確認します。

直接 Lambda 統合のリソースポリシーの例:

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [{
      "Effect": "Allow",
      "Principal": {
         "Service": [
            "transfer.amazonaws.com",
            "apigateway.amazonaws.com"
         ]
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:function-name"
   }]
}
```

## ID プロバイダーの移行中のユーザー保存
<a name="user-preservation-during-transitions"></a>

ID プロバイダータイプを変更する場合、問題が発生した場合に効率的なロールバックを可能にするために、特定のシナリオで既存のユーザー設定が保持されます。
+ **サービスマネージドからカスタム ID プロバイダーおよびバック** – サービスマネージドからカスタム ID プロバイダーに変更してからサービスマネージドに戻すと、すべてのユーザーは最後の既知の設定に保持されます。
+ から**AWS Directory Service カスタム ID プロバイダーに戻り**、 からカスタム ID プロバイダー AWS Directory Service に変更してから に戻ると AWS Directory Service、委任アクセスグループのすべての定義が最後の既知の設定に保持されます。

この保存動作により、ユーザーアクセス設定を失うことなく、カスタム ID プロバイダー設定を安全にテストし、以前の設定にロールバックできます。

## ID プロバイダーを変更する際の重要な考慮事項
<a name="identity-provider-considerations"></a>
+ **ユーザー移行** – ID プロバイダータイプを変更しても、既存のユーザー設定は自動的に移行されません。新しい ID プロバイダーシステムでユーザーを設定する必要があります。
+ **テスト** – 本番環境に変更を加える前に、新しい ID プロバイダー設定を徹底的にテストします。
+ アクセス**許可** – 変更を行う前に、新しい ID プロバイダーに必要な IAM アクセス許可とロールが設定されていることを確認します。