翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# アクセスコントロールの管理
AWS Identity and Access Management (IAM) ポリシーを使用して、 AWS Transfer Family リソースへのユーザーのアクセスを制御できます。IAM ポリシーは、通常は JSON 形式のステートメントで、リソースへの特定のレベルのアクセスを許可するものです。IAM ポリシーを使用して、ユーザーの実行を許可するファイル操作を定義します。IAM ポリシーを使用すると、ユーザーにアクセス権を与える Amazon S3 バケットも定義できます。これらのポリシーをユーザーに指定するには、IAM ポリシーと信頼関係 AWS Transfer Family が関連付けられている の IAM ロールを作成します。
ユーザーごとにロールが割り当てられます。が AWS Transfer Family 使用する IAM ロールのタイプは、*サービスロール*と呼ばれます。ユーザーがサーバーにログインすると、 はユーザーにマッピングされた IAM ロールを AWS Transfer Family 引き受けます。Amazon S3 バケットへのユーザーアクセスを提供する IAM ロールの作成については、*IAM ユーザーガイド*の[「 AWS サービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
IAM ポリシー内の特定のアクセス許可を使用して、Amazon S3 オブジェクトへの書き込み専用アクセスを許可できます。詳細については、「[ファイルの書き込みとリストのみの権限を付与します。](configure-storage.md#headobject-access-denied)」を参照してください。
AWS ストレージブログには、最小特権アクセスを設定する方法を説明する投稿が含まれています。詳細については、[AWS Transfer Family 「ワークフローでの最小特権アクセスの実装](https://aws.amazon.com/blogs//storage/implementing-least-privilege-access-in-an-aws-transfer-family-workflow/)」を参照してください。
**注記**
Amazon S3 バケットが AWS Key Management Service (AWS KMS) を使用して暗号化されている場合は、ポリシーで追加のアクセス許可を指定する必要があります。詳細については、「[データ保護と暗号化](encryption-at-rest.md)」を参照してください。さらに、*IAM ユーザーガイド*でも[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session.html)に関する詳細をご覧いただけます。
**Topics**
+ [Amazon S3 バケットへの読み書きアクセスの許可](users-policies-all-access.md)
+ [Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md)
+ [動的なアクセス許可管理アプローチ](dynamic-permission-management.md)
# Amazon S3 バケットへの読み書きアクセスの許可
このセクションでは、特定の Amazon S3 バケットへの読み取りと書き込みアクセスを許可する IAM ポリシーを作成する方法について説明します。この IAM ポリシーを持つ IAM ロールをユーザーに割り当てると、指定された Amazon S3 バケットへの読み書きアクセスがそのユーザーに付与されます。
以下のポリシーは、Amazon S3 バケットへのプログラムによる読み取り、書き込み、タグ付けアクセスを提供します。`GetObjectACL`および`PutObjectACL`ステートメントは、クロスアカウントアクセスを有効にする必要がある場合にのみ必要です。つまり、Transfer Family サーバーは、別のアカウントのバケットにアクセスする必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid":"ReadWriteS3",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObjectVersion",
"s3:GetObjectVersionTagging",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
}
]
}
```
`ListBucket` アクションには、バケット自体のアクセス許可が必要です。`PUT`、`GET`、および `DELETE` アクションにはオブジェクトのアクセス許可が必要です。これらは異なるリソースなので、異なるAmazonリソースネーム（ARN）を使って指定されます。
指定した Amazon S3 バケットの `home` プレフィックスのみにユーザーのアクセスをさらに制限するには、[Amazon S3 バケットのセッションポリシーの作成](users-policies-session.md) を参照してください。
# Amazon S3 バケットのセッションポリシーの作成
*セッションポリシー*は、Amazon S3 バケットの特定の部分にユーザーを制限する AWS Identity and Access Management (IAM) ポリシーです。 Amazon S3 そのために、リアルタイムでアクセスが評価されます。
**注記**
セッションポリシーは Amazon S3 でのみ使用されます。Amazon EFS では、POSIX ファイルパーミッションを使用してアクセスを制限します。
Amazon S3 バケットの特定の部分への同じアクセス権をユーザーのグループに付与する必要がある場合は、セッションポリシーを使用できます。たとえば、あるユーザーのグループが `home` ディレクトリのみにアクセスする必要があるとします。そのユーザーのグループは同じ IAM ロールを共有します。
**注記**
セッションポリシーの最大長は 2048 文字です。詳細については、*API リファレンス*で `CreateUser` アクションの「[ポリシーリクエストパラメータ](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_RequestSyntax)」を参照してください。
セッションポリシーを作成するには、以下の IAM ポリシーのポリシー変数を使用します。
+ `${transfer:HomeBucket}`
+ `${transfer:HomeDirectory}`
+ `${transfer:HomeFolder}`
+ `${transfer:UserName}`
**重要**
管理ポリシーで先に表示されている変数を先に表示することはできません。IAM ロールの定義のリストでこれらをポリシー変数として使用することもできません。このような変数は、IAM ポリシーで作成してから、ユーザーの設定時に直接指定します。また、セッションポリシーの `${aws:Username}` 変数を使用することはできません。この変数は IAM ユーザー名を指し、 AWS Transfer Familyが要求するユーザー名ではありません。
## セッションポリシーの例
次のコードは、セッションポリシーの例を示しています。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::${transfer:HomeBucket}"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:HomeFolder}/*",
"${transfer:HomeFolder}"
]
}
}
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion",
"s3:GetObjectACL",
"s3:PutObjectACL"
],
"Resource": "arn:aws:s3:::${transfer:HomeDirectory}/*"
}
]
}
```
**注記**
前述のポリシーの例では、ユーザーのホームディレクトリがディレクトリであることを示すために、末尾のスラッシュを含むように設定されていることを前提としています。一方、ユーザーの `HomeDirectory` の末尾にスラッシュを付けない場合、それをポリシーの一部として含める必要があります。
前のポリシー例では、`transfer:HomeFolder`、`transfer:HomeBucket`、および`transfer:HomeDirectory` ポリシーパラメータの使用に注目してください。これらのパラメータは、「[HomeDirectory](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectory)」と [API Gateway メソッドを実装する](authentication-api-gateway.md#authentication-api-method) で説明するように、ユーザー用に構成された `HomeDirectory` について設定されています。これらのパラメータには、次のような定義があります。
+ `transfer:HomeBucket` パラメータは `HomeDirectory` の 1 つ目のコンポーネントに置き換わります。
+ `transfer:HomeFolder` パラメータは `HomeDirectory` パラメータの残り部分に置き換わります。
+ `transfer:HomeDirectory` パラメータの先頭に付いていた (`/`) が削除され、`Resource` ステートメントで S3 Amazon リソースネーム (ARN) の一部としてこのパラメータを使用できるようになりました。
**注記**
論理ディレクトリを使用する場合（つまり、ユーザーの `homeDirectoryType` が `LOGICAL` である場合）、これらのポリシーパラメータ（`HomeBucket`、`HomeDirectory`、および `HomeFolder`）はサポートされません。
たとえば、Transfer Family ユーザー用に設定された `HomeDirectory` パラメータは `/home/bob/amazon/stuff/` です。
+ `transfer:HomeBucket` は `/home` に設定されます。
+ `transfer:HomeFolder` は `/bob/amazon/stuff/` に設定されます。
+ `transfer:HomeDirectory` は `home/bob/amazon/stuff/` になります。
1 つ目の `"Sid"` は、`/home/bob/amazon/stuff/` から始まるすべてのディレクトリの一覧表示をユーザーに許可します。
2 つ目の `"Sid"` は、ユーザーの `put` およびその同じパス `/home/bob/amazon/stuff/` への `get` アクセスを制限します。
前述のポリシーが使用されている場合、ユーザーがログインすると、ユーザーはホームディレクトリにあるオブジェクトにのみアクセスできます。接続時に、 はこれらの変数をユーザーに適した値 AWS Transfer Family に置き換えます。これによって、同じポリシードキュメントを複数のユーザーに簡単に適用できます。この方法により、IAM ロールのオーバーヘッドおよび Amazon S3 バケットへのユーザーのアクセスを管理するためのポリシー管理が軽減されます。
セッションポリシーを使用すると、業務要件に基づいて、ユーザーごとにアクセス権をカスタマイズすることもできます。詳細については、*IAM ユーザーガイド*の「[AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_assumerole.html)」を参照してください。
**注記**
AWS Transfer Family は、ポリシーの Amazon リソースネーム (ARN) ではなく、ポリシー JSON を保存します。したがって、IAM コンソールでポリシーを変更するときは、 AWS Transfer Family コンソールに戻り、最新のポリシーコンテンツでユーザーを更新する必要があります。[**ユーザー設定**] セクションの[**ポリシー情報**] タブでユーザーを更新できます。
を使用している場合は AWS CLI、次のコマンドを使用してポリシーを更新できます。
```
aws transfer update-user --server-id server --user-name user --policy \
"$(aws iam get-policy-version --policy-arn policy --version-id version --output json)"
```
## セッションポリシーのネストされた置換
ネストされた置換は、Transfer Family セッションポリシーでは実行されません。セッションポリシーでは、 などのネストされた変数を使用できます`${transfer:HomeDirectory}`。ポリシーが処理されると、外部変数 (例: `${transfer:HomeDirectory}`) が別の変数 (例: \$1`amzn-s3-demo-bucket:/$(transfer:UserName}`) を含む値に置き換えられることがあります。ただし、ネストされた変数は実際のユーザー名 (**johndoe** など) に置き換えられることはありません。
つまり、Transfer Family のセッションポリシーを作成するときは、この動作を考慮し、ポリシー構造と変数の使用が適切に設計されていることを確認する必要があります。ネストされた変数は想定どおりに解決されず、ポリシーは意図したアクセス許可を付与しない場合があります。セッションポリシーを徹底的にテストして検証し、期待どおりに動作することを確認することが重要です。この動作は、Transfer Family 環境にアクセス制御とアクセス許可を実装する際の重要な考慮事項です。
この問題の解決策の 1 つは、セッションポリシーで実際の Amazon S3 バケット名を使用することです。したがって、例えば、セッションポリシー`${transfer:HomeDirectory}`で を指定するのではなく、amzn-s3-demo-bucket が実際のバケットである を使用します`${amzn-s3-demo-bucket/transfer:UserName}`。
# 動的なアクセス許可管理アプローチ
## Transfer Family アクセス許可アーキテクチャについて
AWS Transfer Family は、セッションポリシーによる動的アクセス許可管理をサポートしています。これにより、実行時に IAM ロールの有効なアクセス許可を制限できます。このアプローチは、サービスマネージドユーザーとカスタム ID プロバイダーユーザーの両方で機能しますが、(Amazon EFS ではなく) Amazon S3 との間でファイルを転送する場合にのみサポートされます。
すべての AWS Transfer Family ユーザーは、以下で構成されるアクセス許可モデルで動作します。
1. *基本 IAM ロール* - ユーザーの基本的なアクセス許可を定義します
1. *オプションのセッションポリシー* - 実行時に基本アクセス許可を制限 (スコープダウン) します
有効なアクセス許可は、基本ロールのアクセス許可とセッションポリシーのアクセス許可の共通部分です。セッションポリシーはアクセス許可のみを制限できます。基本ロールが許可する範囲を超えて追加のアクセス許可を付与することはできません。
このアーキテクチャは、両方のユーザータイプに適用されます。
+ *サービスマネージドユーザー* - セッションポリシーはユーザー設定で直接設定できます
+ *カスタム ID プロバイダーユーザー* - セッションポリシーは、認証レスポンスの一部として返すか、 に保存できます。 AWS Secrets Manager
## アクセス許可管理の 2 つのアプローチ
一意のアクセスパターンを必要とする 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/`できます。
## セッションポリシーの実装
セッションポリシーは、ユーザーに割り当てられた基本 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 と、ファイルシステム自体内に適用されるアクセス許可ビットによって管理されます。
## ユーザータイプ別の実装
サービスマネージドユーザー
サービスマネージドユーザーの場合、 AWS Transfer Family コンソール、API、または CLI を使用して、ユーザー設定でセッションポリシーを直接指定できます。詳細については、「[サービスマネージドユーザーの使用](service-managed-users.md)」を参照してください。
カスタム ID プロバイダーユーザー
カスタム ID プロバイダーユーザーの場合、次の 2 つの方法でセッションポリシーを指定できます。
+ セッションポリシー`Policy`を持つ という名前のキーを値として含め AWS Secrets Manager ることで を経由する
+ 認証結果の一部として Lambda 関数レスポンスまたは API Gateway レスポンスで直接
詳細については、「[カスタム ID プロバイダーソリューション](custom-idp-toolkit.md)」を参照してください。
## 例: セッションポリシーによるロール管理の簡素化
この例では、動的アクセス許可管理がセキュリティを維持しながら管理オーバーヘッドを大幅に削減する方法を示します。
### シナリオ
組織には、ファイルを転送するために SFTP アクセスを必要とするユーザーが 50 人います。各ユーザーは、 という名前の共有 Amazon S3 バケット内の独自のフォルダにのみアクセスする必要があります`company-transfers`。セッションポリシーがない場合、50 個の個別の IAM ロールを作成する必要があります。
従来のアプローチ (セッションポリシーなし)
+ 、`TransferRole-Alice`、 `TransferRole-Charlie`など `TransferRole-Bob`50 個の IAM ロールを作成します。
+ 各ロールには、そのユーザーのフォルダのみに対する特定のアクセス許可があります
+ アクセス許可を管理するには、個々のロールを更新する必要があります
+ 新しいユーザーを追加するには、新しいロールを作成する必要があります
動的アプローチ (セッションポリシーを使用)
+ 1 つの IAM ロールを作成する: バケット全体に対する広範なアクセス許可`TransferRole-Shared`を持つ
+ セッションポリシーを使用して、実行時に各ユーザーを特定のフォルダに制限する
+ アクセス許可を管理するには、1 つのロールまたはセッションポリシーテンプレートを更新する必要があります
+ 新しいユーザーを追加する場合、新しいロールは必要ありません。ユーザー設定だけです。
### 実装
動的アプローチを実装する方法は次のとおりです (`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}/`