Transfer Family アクセス許可アーキテクチャについてアクセス許可管理の 2 つのアプローチセッションポリシーの実装ユーザータイプ別の実装例: セッションポリシーによるロール管理の簡素化

動的なアクセス許可管理アプローチ

Transfer Family アクセス許可アーキテクチャについて

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

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

基本 IAM ロール - ユーザーの基本的なアクセス許可を定義します
オプションのセッションポリシー - 実行時に基本アクセス許可を制限 (スコープダウン) します

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

このアーキテクチャは、両方のユーザータイプに適用されます。

サービスマネージドユーザー - セッションポリシーはユーザー設定で直接設定できます
カスタム 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 バケットのセッションポリシーの作成。

動的生成

カスタム 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 を使用して、ユーザー設定でセッションポリシーを直接指定できます。詳細については、「サービスマネージドユーザーの使用」を参照してください。

カスタム ID プロバイダーユーザー

カスタム ID プロバイダーユーザーの場合、次の 2 つの方法でセッションポリシーを指定できます。

セッションポリシーPolicyを持つという名前のキーを値として含め AWS Secrets Manager ることでを経由する
認証結果の一部として Lambda 関数レスポンスまたは API Gateway レスポンスで直接

詳細については、「カスタム ID プロバイダーソリューション」を参照してください。

例: セッションポリシーによるロール管理の簡素化

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

シナリオ

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

従来のアプローチ (セッションポリシーなし）

、TransferRole-Alice、 TransferRole-Charlieなど TransferRole-Bob50 個の IAM ロールを作成します。
各ロールには、そのユーザーのフォルダのみに対する特定のアクセス許可があります
アクセス許可を管理するには、個々のロールを更新する必要があります
新しいユーザーを追加するには、新しいロールを作成する必要があります

動的アプローチ (セッションポリシーを使用）

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

実装

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

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

広範な 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"
    }
  ]
}

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


{
  "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}*"
        }
      }
    }
  ]
}

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

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

セッションポリシーの作成

CloudTrail ロギング