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

# 動的なアクセス許可管理アプローチ
<a name="dynamic-permission-management"></a>

## Transfer Family アクセス許可アーキテクチャについて
<a name="permission-architecture-overview"></a>

AWS Transfer Family は、セッションポリシーによる動的アクセス許可管理をサポートしています。これにより、実行時に IAM ロールの有効なアクセス許可を制限できます。このアプローチは、サービスマネージドユーザーとカスタム ID プロバイダーユーザーの両方で機能しますが、Amazon S3 (Amazon EFS ではなく) との間でファイルを転送する場合にのみサポートされます。

すべての AWS Transfer Family ユーザーは、以下で構成されるアクセス許可モデルで動作します。

1. *基本 IAM ロール* - ユーザーの基本的なアクセス許可を定義します

1. *オプションのセッションポリシー* - 実行時に基本アクセス許可を制限 (スコープダウン) します

有効なアクセス許可は、基本ロールのアクセス許可とセッションポリシーのアクセス許可の共通部分です。セッションポリシーはアクセス許可のみを制限できます。基本ロールが許可する範囲を超えて追加のアクセス許可を付与することはできません。

このアーキテクチャは、両方のユーザータイプに適用されます。
+ *サービスマネージドユーザー* - セッションポリシーはユーザー設定で直接設定できます
+ *カスタム ID プロバイダーユーザー* - セッションポリシーは、認証レスポンスの一部として返すか、 に保存できます。 AWS Secrets Manager

## アクセス許可管理の 2 つのアプローチ
<a name="permission-management-approaches"></a>

一意のアクセスパターンを必要とする Transfer Family ユーザーのアクセス許可を設計する場合、次の 2 つの主要なアプローチから選択できます。

ユーザーごとに 1 つのロール  
Transfer Family ユーザーごとに、そのユーザーのニーズに合わせた特定のアクセス許可を持つ個別の IAM ロールを作成します。このアプローチは、次の場合に使用します。  
+ 各ユーザーには、非常に異なるアクセス許可が必要です
+ アクセス許可の管理は、組織内のさまざまなユーザーによって処理されます。
+ 個々のユーザーアクセスをきめ細かく制御する必要がある

セッションポリシーと共有ロール  
広範なアクセス許可 (複数のユーザーホームディレクトリを含む Amazon S3 バケット全体へのアクセスなど) を持つ単一の IAM ロールを使用し、セッションポリシーを適用して各ユーザーを特定のエリアに制限します。このアプローチにより、ユーザーごとに個別のロールを管理するよりも、管理オーバーヘッドが大幅に削減されます。このアプローチは、次の場合に使用します。  
+ ユーザーには同様のタイプのアクセスが必要ですが、リソースは異なります (たとえば、すべてのユーザーには読み取り/書き込みアクセスが必要ですが、それぞれが独自のフォルダにのみ必要です）。
+ ロール管理を簡素化し、数十または数百の個々のロールを作成しないようにしたい
+ ユーザーは、共有バケット内の指定されたホームディレクトリにのみアクセスする必要があります
+ アクセス許可の管理は組織内で一元化されます
例えば、ユーザー「alice」、「bob」、「charlie」に対して個別のロールを作成する代わりに、`s3://company-transfers/`バケット全体にアクセスできるロールを 1 つ作成し、セッションポリシーを使用して、alice を `s3://company-transfers/alice/`、bob を `s3://company-transfers/bob/`などに制限できます。

## セッションポリシーの実装
<a name="session-policy-implementation"></a>

セッションポリシーは、ユーザーに割り当てられた基本 IAM ロールの有効なアクセス許可を制限することで機能します。最後のアクセス許可は、ロールのアクセス許可とセッションポリシーのアクセス許可の共通部分です。

動的セッションポリシーは、次の 2 つの方法で実装できます。

変数の置換  
セッションポリシー`${transfer:HomeBucket}`で、`${transfer:Username}`、`${transfer:HomeDirectory}`、 などの Transfer Family ポリシー変数を使用します。これらの変数は、実行時に実際の値に自動的に置き換えられます。これらの変数の詳細については、「」を参照してください[Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md)。

動的生成  
カスタム ID プロバイダーの場合、Lambda 関数または API Gateway メソッドからの認証レスポンスの一部として、on-the-flyでセッションポリシーを生成します。このアプローチにより、認証時にユーザー属性、グループメンバーシップ、または外部データソースに基づいて高度にカスタマイズされたポリシーを作成できます。  
セッションポリシー JSON `Policy`を持つ という名前のキーを値として含め AWS Secrets Manager ることで、事前に生成されたセッションポリシーを に保存することもできます。これにより、ユーザー固有のアクセスコントロールを維持しながら、複数のユーザー間で同じ広範な IAM ロールを使用できます。

**注記**  
セッションポリシーは、Amazon S3 との間のファイル転送でのみサポートされています。Amazon EFS ファイルシステムには適用されません。Amazon EFS の場合、アクセス許可は UID/GID と、ファイルシステム自体内に適用されるアクセス許可ビットによって管理されます。

## ユーザータイプ別の実装
<a name="implementation-by-user-type"></a>

サービスマネージドユーザー  
サービスマネージドユーザーの場合、 AWS Transfer Family コンソール、API、または CLI を使用して、ユーザー設定でセッションポリシーを直接指定できます。詳細については、「[サービスマネージドユーザーの使用](service-managed-users.md)」を参照してください。

カスタム ID プロバイダーユーザー  
カスタム ID プロバイダーユーザーの場合、次の 2 つの方法でセッションポリシーを指定できます。  
+ セッションポリシー`Policy`を持つ という名前のキーを 値として含め AWS Secrets Manager ることによる 経由
+ 認証結果の一部として Lambda 関数レスポンスまたは API Gateway レスポンスで直接
詳細については、「[カスタム ID プロバイダーソリューション](custom-idp-toolkit.md)」を参照してください。

## 例: セッションポリシーによるロール管理の簡素化
<a name="dynamic-permission-example"></a>

この例では、動的アクセス許可管理が、セキュリティを維持しながら管理オーバーヘッドを大幅に削減する方法を示します。

### シナリオ
<a name="scenario-description"></a>

組織には、ファイルを転送するために SFTP アクセスを必要とするユーザーが 50 人います。各ユーザーは、 という名前の共有 Amazon S3 バケット内の独自のフォルダにのみアクセスする必要があります`company-transfers`。セッションポリシーがない場合、50 個の個別の IAM ロールを作成する必要があります。

従来のアプローチ (セッションポリシーなし)  
+ 、`TransferRole-Alice`、 `TransferRole-Charlie`など `TransferRole-Bob`50 個の IAM ロールを作成します。
+ 各ロールには、そのユーザーのフォルダのみに対する特定のアクセス許可があります
+ アクセス許可を管理するには、個々のロールを更新する必要があります
+ 新しいユーザーを追加するには、新しいロールを作成する必要があります

動的アプローチ (セッションポリシーを使用)  
+ IAM ロールを 1 つ作成する: バケット全体に対する広範なアクセス許可`TransferRole-Shared`を持つ
+ セッションポリシーを使用して、実行時に各ユーザーを特定のフォルダに制限する
+ アクセス許可を管理するには、1 つのロールまたはセッションポリシーテンプレートを更新する必要があります
+ 新しいユーザーを追加する場合、新しいロールは必要ありません。ユーザー設定だけです。

### 実装
<a name="implementation-example"></a>

動的アプローチを実装する方法は次のとおりです (`company-transfers`バケットを例として使用して実際の Amazon S3 バケットに置き換えます）。

**動的アクセス許可管理を実装するには**

1. 広範な Amazon S3 アクセス許可を持つ共有 IAM ロールを 1 つ作成します。  
****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::company-transfers/*"
       },
       {
         "Effect": "Allow",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::company-transfers"
       }
     ]
   }
   ```

1. ユーザーの フォルダへのアクセスを制限するセッションポリシーテンプレートを作成します。  
****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::company-transfers/${transfer:Username}/*"
       },
       {
         "Effect": "Allow",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::company-transfers",
         "Condition": {
           "StringLike": {
             "s3:prefix": "${transfer:Username}*"
           }
         }
       }
     ]
   }
   ```

1. 以下を使用して各ユーザーを設定します。
   + 共有 IAM ロール
   + セッションポリシーは次のように適用されます。
     + *サービスマネージドユーザー*: API または CLI を使用して、ユーザーを作成または変更するときに Policy パラメータを介して JSON を適用します (コンソールには事前定義されたポリシーオプションのみが用意されています）。
     + *カスタム ID プロバイダーユーザー*: 認証中に Lambda 関数レスポンスの一部として返すか、ユーザーの認証情報とともに「ポリシー」という名前のキー AWS Secrets Manager として に保存します。
   + ホームディレクトリ: `/company-transfers/${transfer:Username}/`