Amazon S3 Access Grants によるデータアクセスの拡張

最小権限の原則に従い、ユーザーはアプリケーション、ペルソナ、グループ、組織単位（OU）に基づいて、Amazon Simple Storage Service（Amazon S3）のデータへのきめ細やかなアクセスを定義します。この方法は、不正アクセスのリスクを軽減し、セキュリティ侵害が発生した場合の損害を抑制するのに役立ちます。従業員が自分のタスクに不可欠なリソースへのアクセスのみを持つため、不注意による誤ったデータの取り扱いミスを抑制します。さらに、お客様は精密なユーザーアクティビティの追跡と分析を可能にする包括的な監査機能を望んでいます。この機能は、規制要件と内部ガバナンス基準への遵守に不可欠であり、異常な振る舞いやセキュリティインシデントの迅速な検出を可能にします。

先日、Amazon Web Services（AWS）は、新機能として Amazon S3 Access Grants を発表しました。これは、Microsoft Entra（以前の Microsoft Azure AD）や Okta などのディレクトリ内のアイデンティティを Amazon S3 のデータセットにマッピングすることをユーザーに可能にします。これにより、ユーザーは企業アイデンティティに基づいてエンドユーザーに適切な Amazon S3 アクセスを自動的に付与することで、大規模にデータ権限を管理することができます。S3 Access Grants は、AWS Identity and Access Management（IAM）と共に使用することも可能であり、Amazon S3 内の既存のリソースレベルのコントロール（例えば S3 バケットポリシー）を補完する簡単でスケーラブルな方法として利用できます。さらに、S3 Access Grants は、Amazon S3 データへのアクセスに使用されたエンドユーザーのアイデンティティとアプリケーションを AWS CloudTrail に記録します。これは、S3 バケット内のすべてのデータアクセスの詳細な監査履歴を提供するのに役立ちます。

この投稿では、S3 Access Grants とその構成についての概要を提供し、特定のアクセスパターンに基づいて S3 Access Grants の使用方法を例示します。これには、 IAM プリンシパルとの S3 Access Grants の使用方法と、企業ディレクトリからのユーザーやグループとの使用方法が含まれます。

大規模な詳細アクセスを実現

現在、ユーザーは Amazon S3 のデータへの詳細なアクセスを達成するために、アクセスパターンの規模と複雑さに応じてさまざまなアプローチを持っています。

Amazon S3 のデータへの詳細なアクセスを達成する方法は、アクセスパターンの規模と複雑さに基づいて変わります。小規模なデータセットの場合、ユーザーは通常、ポリシーサイズの制限内に収まる限り、 IAM アクセスポリシーとバケットポリシーを使用します。データセットとユースケースの数が増えるにつれて、AWS アカウント毎のリージョンあたり数千のアクセスポイントを許可する Amazon S3 アクセスポイントを使用するという代替オプションがあります。ただし、このアプローチには、データセットに適したアクセスポイントを見つけるための追加ロジックが必要であり、静的なアクセスパターンに適しています。データ権限の複雑で洗練された評価が必要な場合、第三のアプローチが検討され、ここでは「IAM セッションブローカー」パターンを採用し、ユーザーはアクセス決定のロジックを処理し、動的に短期の IAM セッション資格情報を生成します。この方法はスケーラビリティをサポートしていますが、ユーザー自身でアクセスパターンロジックを設計および実装する必要があります。

これらのアプローチではすべて、Amazon S3 データアクセスをユーザーやグループにマッピングし、アクセスを監査することに、ある程度のオーバーヘッドがあります。S3 Access Grants と IAM Identity Center の新しい Trusted Identity Propagation は、ユーザーやグループへの Amazon S3 の詳細なアクセスを管理するというこの複雑で時間のかかる作業をユーザーから取り除きます。

S3 Access Grants は、バケット、プレフィックス、またはオブジェクトレベルでの読み取り専用、書き込み専用、または読み書きアクセスなどの単純な権限を定義することをユーザーに可能にします。その後、ユーザーは IAM プリンシパルを S3 Access Grants に割り当てることができます。または、AWS IAM Identity Center との統合を使用して、企業ディレクトリからユーザーやグループにアクセスを割り当てることができます。IAM Identity Center との統合を使用する場合、ユーザーはディレクトリにユーザーを認証する企業アプリケーションを持ち込むことができ、IAM Identity Center API との統合に数行のコードを追加することで、それらのアプリケーションが認証された各ユーザーの代理として Amazon S3 上のデータにアクセスできるようになります。さらに、IAM Identity Center 統合を使用すると、ユーザーのアイデンティティが Amazon S3 データへのすべてのアクセスとともに記録されるため、誰が何にアクセスしたかの監査が可能になります。

Amazon S3 Access Grants は、あなたのユースケースに適していますか？

Amazon S3 での多くの権限ユースケースは、IAM プリンシパルと S3 バケットの両方に対して IAM ポリシーを使用して、簡単かつ効果的に実装することができます。小規模なユースケースには、このアプローチをお勧めします。S3 Access Grants は、次のような状況で S3 でのデータ権限の管理を簡素化します：

• Amazon S3 に大量のデータセットがあり、IAM や S3 バケットポリシーの文字数制限が懸念される場合。
• 権限スキームがユーザー/グループからデータセットへのパターンにより自然に適合し、中間の IAM ロールを使用してアクセスを得るよりも、ディレクトリグループに直接権限を割り当てる方が簡単な場合。
• より複雑な多対多のユーザーからデータへのマッピング、例えば個々のユーザーが複数のグループのメンバーであり、そのための Amazon S3 内のデータセットの和集合へのアクセスが必要なケース。

S3 Access Grants の仕組みを詳しく説明する前に、S3 Access Grants のさまざまな構成要素を理解しましょう。

Amazon S3 Access Grants – コンセプト

S3 Access Grants は、その簡略化されたアクセススキームのためにいくつかのコンセプトを導入します。まず、それらを定義していきます。

S3 Access Grants インスタンス: S3 Access Grants インスタンスは、Amazon S3 データへのアクセスレベルが誰にどのように付与されているかを定義する個々の権限の論理的なグループです。1 つの AWS アカウント内の 1 つの AWS リージョンごとに 1 つのインスタンスを設定できます。このアカウントおよびリージョンレベルの S3 Access Grants インスタンスは、同じアカウントおよび AWS リージョンのすべてのバケットへのアクセスを制御できます。外部ディレクトリのユーザーやグループにアクセスを付与するために S3 Access Grants を使用する場合は、S3 Access Grants インスタンスを IAM Identity Center インスタンスに関連付ける必要があります。他の AWS アカウントの IAM プリンシパルにアクセスを付与する場合は、これらのクロスアカウント API 呼び出しを許可するために、S3 Access Grants インスタンスにリソースベースのポリシーを使用します。

ロケーション: S3 Access Grants は、特定の Amazon S3 プレフィックスへのアクセスをスコープとした IAM 資格情報を発行することで機能します。S3 Access Grants ロケーションは、これらの一時セッションが作成される IAM ロールに関連付けられています。最も一般的な設定は、すべての S3 Access Grants に対して s3:// で単一のロケーションを使用することで、AWS リージョンおよびアカウント内のすべての S3 バケットへのアクセスをカバーできます。S3 Access Grants はこれを「デフォルト」ロケーションと呼びます。より高度なユースケースで複数の異なる IAM ロールの使用が必要な場合、お客様はそれを行うために複数の S3 Access Grants ロケーションを作成できます。

権限: S3 Access Grants の個々の権限は、特定のエンティティ（IAM プリンシパル、ディレクトリユーザー、またはディレクトリグループ）に対して、S3 バケット、プレフィックス、またはオブジェクトへのアクセスを許可します。たとえば、特定のディレクトリグループ 01234567-89ab-cdef-0123-456789abcdef に s3://DOC-EXAMPLE-BUCKET/projects/foo/* への READ アクセスを許可する権限を持っている場合、そのグループのユーザーはそのバケット内の projects/foo/ の下のすべてに読み取りアクセスを許可されます。

S3 Access Grants の一時的な資格情報: アプリケーションは、新しい Amazon S3 API、GetDataAccess を呼び出して、単一のオブジェクト、プレフィックス、またはバケットへのアクセス権限をリクエストし、READ、WRITE、または READWRITE の権限レベルを要求します。S3 Access Grants 機能はリクエストを設定された権限に対して評価します。一致する権限があれば、その権限のロケーションに関連付けられた IAM ロールを引き継ぎ、権限を IAM セッションの権限に正確にスコープし、Amazon S3 プレフィックスまでの権限を与えます。アクセス資格情報の有効期限はデフォルトで 1 時間ですが、15 分から 36 時間まで任意の値に設定することができます。

これらの構成を例を挙げて理解しましょう。最初のセクションではシナリオを説明し、次にそのシナリオに対して S3 Access Grants を実装します。

Amazon S3 Access Grants – セットアップ

私たちが説明する例において、S3 Access Grants がどのようにマップされるかを理解するために、 developerRole および analystRole 、2 つの IAM ロールを定義します。重要なのは、ロールは実際の人々ではなく、人々やサービスが引き受ける役割であるということです。後ほど、IAM Identity Center を使用して、アクセスが実際のユーザーやグループに基づいていることを示します。

アクセスパターンのシナリオ

以下の図では、s3:// でスコープが定義されたデフォルトの Amazon S3 のロケーションと、アカウント内で Amazon S3 のアクションを実行する権限を持つ IAM ロール s3ag-location-role が定義されています。S3 Access Grants は、アクセスのリクエストに対してこの IAM ロールを使用して一時的な資格情報を作成します。

次に、以下のアクセスを定義します。IAM ロール developerRole は、developer/ プレフィックスに対して READ および WRITE のアクセス権を持ちます。別の IAM ロール analystRole は、analysis/ プレフィックスに対して READ アクセスのみが許可されます。左側の S3 Access Grants（青色で表示）は、DOC-BUCKET-EXAMPLE バケット内のプレフィックス developer/ へのアクセスを developerRole に与えるために定義されています。右側の S3 Access Grants（緑色で表示）は、DOC-BUCKET-EXAMPLE バケット内のプレフィックス analysis/ へのアクセスを analystRole に与えるために定義されています。これは 図 1 で示されています。

図 1: S3 Access Grants の概要

図 1 に示されているように、Bob がデータを読む時、developerRole IAM ロールを使用して S3 Access Grants GetDataAccess API を呼び出します。 s3://DOC-BUCKET-EXAMPLE/developer/ で始まる任意の Amazon S3 プレフィックスまたはオブジェクトへの READ 権限を要求する場合、GetDataAccess は s3://DOC-BUCKET-EXAMPLE/developer/* への権限を持つ S3 Access Grants の一時的な資格情報を返します。同様に、WRITE アクセスを要求することもできます。なぜなら、権限はそれも許可しているからです。

同様に、Alice は analystRole IAM ロールを使用して GetDataAccess を呼び出し、Amazon S3 の s3://DOC-BUCKET-EXAMPLE/analysis/ で始まるものへの READ アクセスを要求できます。そして、S3 Access Grants は適切にスコープされた IAM セッション資格情報を返します。しかし、WRITE 権限を要求する場合、データへの書き込み権限を与える権限がないため、アクセス拒否エラーが発生します。さらに、Alice が s3://DOC-BUCKET-EXAMPLE/developer/ の下のデータへのアクセスを任意のレベルで要求する場合、または Bob が s3://DOC-BUCKET-EXAMPLE/analysis/ の下のデータへのアクセスを任意のレベルで要求する場合も、アクセス拒否となります。

S3 Access Grants インスタンスあたり最大 10 万の権限と 1,000 のロケーションを持つことができます。個々のユーザーとプレフィックスのアクセス許可の組み合わせが追加または削除されるたびに、長く複雑な S3 バケットポリシーを編集する代わりに、各関係に対して個別の権限を追加および削除することができます。

アクセスパターンのシナリオのセットアップ

S3 Access Grants についての基本的な概念を理解したところで、前のセクションで示した権限を作成する方法を見ていきましょう。この例では、IAM ロールdeveloperRole と analystRole、および S3 バケット DOC-EXAMPLE-BUCKET が既に存在しているとします。

1. S3 Access Grants インスタンスの作成: S3 Access Grants インスタンスを作成するには、以下のコマンドを実行します。

aws s3control create-access-grants-instance --account-id 123456789012

2. S3 Access Grants ロケーションの作成: 次のステップは、S3 Access Grants ロケーションを作成することです。これを行うには、S3 Access Grants サービスに信頼を持ち、Amazon S3 リソースへのアクセスを許可する IAM ロールが必要です。この IAM ロールを s3ag-location-role と呼びます。

i. S3 Access Grants IAM ロール:
S3 Access Grants が資格情報を生成できるようにするためには、IAM ロールを作成し、それをロケーションに関連付ける必要があります。IAM ロール信頼ポリシーは、サービスプリンシパル access-grants.s3.amazonaws.com が以下のアクションを実行できるようにする必要があります：
– sts:AssumeRole – 要求者のアイデンティティで IAM 資格情報を生成するために必要
– sts:SetSourceIdentity – IAM ロールを引き受ける権限を使用する場合に必要
– sts:SetContext – DIRECTORY_USER/DIRECTORY_GROUP の権限を使用する場合に必要

trust-policy.json というファイルを作成し、以下の内容をファイルにコピー＆ペーストしてください：
//trust-policy.json

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Principal": {
               "Service": "access-grants.s3.amazonaws.com"
           },
           "Action": [
               "sts:AssumeRole",
               "sts:SetSourceIdentity",
               "sts:SetContext"
           ]
       }
   ]
}

その後、以下のコマンドを実行してください：

aws iam create-role --role-name s3ag-location-role \
        --assume-role-policy-document file://trust-policy.json

ii. IAM ロールに Amazon S3 の権限を付与する IAM ポリシーを作成する

iam-policy.json というファイルを作成してください
//iam-policy.json

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "ObjectLevelReadPermissions",
           "Effect": "Allow",
           "Action": [
               "s3:GetObject",
               "s3:GetObjectVersion",
               "s3:GetObjectAcl",
               "s3:GetObjectVersionAcl",
               "s3:ListMultipartUploadParts"
           ],
           "Resource": [
               "arn:aws:s3:::*"
           ],
           "Condition": {
               "StringEquals": {
                   "aws:ResourceAccount": "{{accountId}}"
               },
               "ArnEquals": {
                   "s3:AccessGrantsInstanceArn": [
                       "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"
                   ]
               }
           }
       },
       {
           "Sid": "ObjectLevelWritePermissions",
           "Effect": "Allow",
           "Action": [
               "s3:PutObject",
               "s3:PutObjectAcl",
               "s3:PutObjectVersionAcl",
               "s3:DeleteObject",
               "s3:DeleteObjectVersion",
               "s3:AbortMultipartUpload"
           ],
           "Resource": [
               "arn:aws:s3:::*"
           ],
           "Condition": {
               "StringEquals": {
                   "aws:ResourceAccount": "{{accountId}}"
               },
               "ArnEquals": {
                   "s3:AccessGrantsInstanceArn": [
                       "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"
                   ]
               }
           }
       },
       {
           "Sid": "BucketLevelReadPermissions",
           "Effect": "Allow",
           "Action": [
               "s3:ListBucket"
           ],
           "Resource": [
               "arn:aws:s3:::*"
           ],
           "Condition": {
               "StringEquals": {
                   "aws:ResourceAccount": "{{accountId}}"
               },
               "ArnEquals": {
                   "s3:AccessGrantsInstanceArn": [
                       "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}"
                   ]
               }
           }
       },
       {
           "Sid": "KMSPermissions",
           "Effect": "Allow",
           "Action": [
               "kms:Decrypt",
               "kms:GenerateDataKey"
           ],
           "Resource": [
               "*"
           ]
       }
   ]
}

注記: この IAM ポリシーでは、プレースホルダー {{accountId}}, {{region}}, および {{instanceId}} を、それぞれあなたのアカウント、AWS リージョン、Access Grants インスタンス ID の情報に置き換える必要があります。上記のポリシーはデフォルトロケーション用です。デフォルト以外のロケーションを作成する場合は、ポリシーのリソース要素内のロケーションリストを更新してください。

その後、以下のコマンドを実行してください：

aws iam put-role-policy --role-name s3ag-location-role --policy-name s3ag-location-role --policy-document file://iam-policy.json

iii. S3 Access Grants ロケーションの作成

IAM ロールを作成したので、アカウント用のデフォルト S3 Access Grants ロケーションを作成し、その IAM ロールと関連付けることができます。

aws s3control create-access-grants-location \
--account-id 123456789012 \
--location-scope s3:// \
--iam-role-arn arn:aws:iam::123456789012:role/s3ag-location-role

ロケーションスコープを s3:// に設定することは、S3 Access Grants ロケーションを作成する際に推奨されるオプションです。これにより、すべての GetDataAccess リクエストに対して s3ag-location-role を使用して資格情報を発行するように S3 Access Grants に指示します。

S3 Access Grants を使用した Amazon S3 データへのアクセス（同一アカウントのシナリオ）

1. アクセス権限の作成:

これで、IAM ロール developerRole と analystRole にそれぞれ developer/ および analysis/ プレフィックスへのアクセス許可を付与する権限を作成することができます。この時点で、developerRole に s3://DOC-EXAMPLE-BUCKET/developer/* への読み書きアクセス権限を与えるための 1 つの権限と、analystRole に s3://DOC-EXAMPLE-BUCKET/analysis/* への読み取り専用アクセス権限を与えるための別の権限を作成できます。

developer/ プレフィックスに developerRole 用の READWRITE S3 Access Grants の権限を作成します。

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/developer/*” \
--permission READWRITE \
--grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/developerRole

analysis/ プレフィックスに analystRole 用の READ S3 Access Grants の権限を作成します。

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/analysis/*” \
--permission READ \
--grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/analystRole

developerRole と analystRole の IAM ロールに Amazon S3 プレフィックスへのアクセスを S3 Access Grants の権限を通じて与えるため、データへの直接的なアクセス権限（例：s3:GetObject アクション）を与える必要はありません。代わりに、各ロールに必要なのは s3:GetDataAccess 、つまり S3 Access Grants からデータへのアクセスを要求する能力です。言い換えれば、S3 Access Grants は、これらの IAM ロールのどれがどのデータセットへのアクセス権を持っているかを評価します。

ここには、IAM ロール developerRole と analystRole に必要な IAM ポリシーの例があります：

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Action": [
               "s3:GetDataAccess"
           ],
           "Resource": [
               "arn:aws:s3:us-east-2:123456789012:access-grants/default"
           ]
       }
   ]
}

developer および analyst の IAM ロールのための権限が現在設定されています。次に、developerRole を使用して Bob がその権限を利用して Amazon S3 のデータを読む方法を示します。

2. 一時的な資格情報のリクエスト:

developerRole を使用して、Bob は S3 Access Grants の GetDataAccess API への API リクエストを行います。

aws s3control get-data-access \
--account-id 123456789012 \
--target s3://DOC-EXAMPLE-BUCKET/bob/developer/*  \
--permission READ

S3 Access Grants はリクエストを行ったプリンシパル、ターゲット、およびリクエストされた権限に基づいてリクエストを評価します。ターゲットがこのバケットとプレフィックスで始まる任意の権限と一致する限り、S3 Access Grants は成功レスポンスを返します。この成功レスポンスは S3 からのデータを返すわけではなく、そのデータにアクセスするための S3 Access Grants の一時的な資格情報を返します。前述のリクエストに対して、GetDataAccess API は成功します。なぜなら呼び出し元である developerRole は、リクエスト (s3://DOC-EXAMPLE-BUCKET/developer/) と一致するターゲット s3://DOC-EXAMPLE-BUCKET/developer/* に権限を持っているためです。

レスポンスは以下のようになります：

{
   "Credentials": {
       "AccessKeyId": "ASIACKCEVSQ6C2EXAMPLE",
       "SecretAccessKey": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
       "SessionToken": "<SessionTokenString...>",
       "Expiration": "2023-11-07T17:34:37+00:00"
   },
   "MatchedGrantTarget": "s3://DOC-EXAMPLE-BUCKET/developer/*"
}

前述の成功レスポンスには一時的な IAM セッションの認証情報が含まれています。これらの認証情報を使用して、アプリケーションは例えば Amazon S3 の GetObject API などの Amazon S3 リクエストを行い、これらの認証情報が有効な期間内に s3://DOC-EXAMPLE-BUCKET/developer/ 下の任意のオブジェクトにアクセスすることができます。言い換えれば、S3 Access Grants アプリケーションは通常、個々のオブジェクトへのアクセスをそれぞれリクエストするべきではありません。代わりに、一致した権限の下での全てのアクセスに対して認証情報を再利用すべきです。

GetDataAccess への任意のリクエストがこの権限と一致する場合、成功レスポンスで同じ MatchedGrantTarget が結果として返されます。例えば、もし Bob が s3://DOC-EXAMPLE-BUCKET/developer/reports/file.txt への READ アクセスをリクエストした場合、それも権限と一致するため、S3 Access Grants は成功します。デフォルトでは、その成功レスポンスには一致した権限の下ですべてにアクセスするための一時的な IAM セッションの認証情報が含まれています。これは s3://DOC-EXAMPLE-BUCKET/developer/ です。ほとんどの S3 Access Grants の使用例では、アプリケーションが同じプレフィックスの下で多くの後続のリクエストを行う可能性が高いため、これが望ましい挙動です。しかし、アプリケーションがより狭い範囲のアクセスを望む場合が稀にあります。その場合、「privilege」オプションのパラメーターを「minimal」の値に設定できます。その場合、S3 Access Grants は特定のリクエストされたオブジェクトにのみアクセスする一時的な IAM セッションの認証情報を返します。

GetDataAccess リクエストと developerRole のレスポンスの例をいくつか示します。この例では、developerRole に対して次の二つの権限があると仮定します：

• s3://DOC-EXAMPLE-BUCKET/developer/* への READ 権限
• s3://DOC-EXAMPLE-BUCKET/developer/reports/* への READ 権限

developerRole への権限に対する privilege の動作を見てみましょう。

前述の例では、Amazon S3 内の 2 つのプレフィックスにロールベースのアクセスを提供することにより、S3 Access Grants の動作を説明しました。S3 内のたった 2 つの IAM ロールと 2 つのデータセットを使用するこのパターンは、直接の IAM 許可技術を使用して十分に実装することができ、そのために S3 Acess Grants は必要ありません。しかし、IAM ロール、Amazon S3 内のプレフィックス、およびアクセスマッピングの数と複雑さが増すにつれて、S3 Access Grants は管理上の利点を持ち始めます。これにより、単一の権限を一つずつ管理できるようになり、大規模に編集すると複雑になることがある一枚岩の IAM ポリシードキュメントの編集よりも効果的です。特に、これらの IAM ロールの一部がバケットとは異なる AWS アカウント内にある場合、S3 バケットポリシーのサイズ制限が、サポートできる異なるアクセスパターンの数に影響します。

次のセクションでは、AWS アカウント間でのアクセスのための S3 Access Grants の設定方法について説明します。

S3 Access Grants を使用した Amazon S3 データへのアクセス（クロスアカウントのシナリオ）

S3 Access Grants インスタンスはリソースベースのポリシーをサポートしています。そのため、適切なリソースベースのポリシーがあれば、S3 Access Grants は他の AWS アカウントの IAM プリンシパルにアクセスを許可するためにも使用することができます。

この例では、AWS アカウント 111111111111 への権限の付与をサポートすることを目的としています。AWS アカウント 111111111111 の IAM プリンシパルが s3:GetDataAccess を使用して S3 内のデータにアクセスすることが期待されているため、このアクションをクロスアカウントで実行することを許可しています。ここに示されている s3:ListAccessGrants と s3:ListAccessGrantsLocations の権限は、このアカウントが S3 Access Grants をリストし、それらを使用してデータにアクセスすることを期待している場合に必要となります。

//s3ag-policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "111111111111"
            },
            "Action": [
                "s3:ListAccessGrants",
                "s3:ListAccessGrantsLocations",
                "s3:GetDataAccess"
            ],
            "Resource": "arn:aws:s3:us-east-2:123456789012:access-grants/default"
        }
    ]
}

このポリシードキュメントを S3 Access Grants インスタンスに割り当てるには、次のコマンドを実行できます：

aws s3control put-access-grants-instance-resource-policy \
--account-id 123456789012 \
--policy file://s3ag-policy.json \
--region us-east-2

この S3 Access Grants インスタンスのポリシーは通常のリソースベースのポリシーであり、IAM ポリシー言語がサポートするすべてをサポートしています。たとえば aws:PrincipalArn 条件を使用してアカウント 111111111111 の特定の IAM プリンシパルにアクセスを許可することもできましたが、通常はここでそれを行う必要はありません。代わりに、S3 Access Grantsインスタンス内で、そのアカウントの個々の IAM プリンシパルに対して詳細な権限を記述します。これらは S3 Access Grants で個別に管理する方が、リソースベースのポリシーで行うよりも簡単です。

以下は、アカウント 1111111111 から testingRole へのクロスアカウント権限付与の図です。

図 2: クロスアカウントアクセスを持つ Access Grants

これまでに、同じ AWS アカウント内および異なる AWS アカウントの IAM プリンシパルにアクセスを許可するために S3 Access Grants を使用することについて話しました。特に強力な機能は、IAM Identity Center との S3 Access Grants の統合によってもたらされる、ディレクトリユーザーとグループに直接権限を付与する能力です。たとえば、組織のユーザーがデータにアクセスするために使用する企業アプリケーションがある場合、これらのユーザーとグループに直接アクセスを許可することができます。これにより、これらのアプリケーションは以前のようにユーザーを IAM ロールにマッピングする必要がなくなります。次のセクションでは、S3 Access Grants をディレクトリユーザーやグループと使用する方法を紹介します。

ディレクトリユーザーの S3 Access Grants を使用した S3 データへのアクセス

S3 Access Grants を AWS IAM Identity Center と一緒に使用する場合、企業ディレクトリ内のユーザーまたはそのグループメンバーシップに基づいてロケーションへのアクセスをユーザーに提供することができます。IAM Identity Center は AWS クラウド内で持っているユーザーを取り込み、AWS 管理アプリケーションや AWS アカウントへの割り当てに利用できるようにする一つの場所を提供します。S3 Access Grants を IAM Identity Center に接続すると、ユーザーは S3 Access Grants を使用してシングルサインオン体験を提供するアプリケーションを通じて Amazon S3 データにアクセスすることができます。これらのユーザーは IAM ロールを直接理解したり使用したりする必要はありません。これによるもう一つの利点は、ユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに記録されることで、誰が（どのユーザーが）データにアクセスしたかを判断する監査作業が簡素化されることです。

S3 Access Grants をこの方法で使用する前に、まず AWS IAM Identity Center を設定する必要があります。詳細については、ワークフォースアイデンティティの管理を参照してください。知っておくべき主なことは、以下の通りです：

1. IAM Identity Center にサポートされているアイデンティティプロバイダーを接続し、既存のユーザーとグループを使用するか、IAM Identity Center 内でユーザーとグループを作成することができます。
2. S3 Access Grants を使用するユーザーとグループを IAM Identity Center にプロビジョニングする必要があります。外部アイデンティティプロバイダーを使用する場合、これはクロスドメインアイデンティティ管理（SCIM）プロトコルを使用して行うのが最適です。
3. ユーザーは、IAM Identity Center と統合されている AWS サービスやアプリケーションを通じてデータにアクセスする必要があります。シングルサインオン体験を通じてデータセットにアクセスするアプリケーションを構築する方法については、このブログ記事を参照してください。

IAM Identity Center の設定方法については、AWS IAM Identity Center を有効にするをご覧ください。

ここでは、企業のユーザーやグループ向けに S3 Access Grants で権限を作成する方法をご紹介します。

IAM Identity Center を有効にし、ID ソースを設定し、ユーザーをプロビジョニングしたら、ユーザーやグループに直接アクセスを許可する準備が整います。その手順は以下の通りです：

1. S3 Access Grants を IAM Identity Center に関連付ける

この手順により、Access Grants で IAM Identity Center のユーザーやグループを参照できるようになります。これは S3 Access Grants コンソールでワンクリックで行うこともできます。

aws s3control associate-access-grants-identity-center \
--account-id 123456789012 \
--identity-center-arn arn:aws:sso:::instance/ssoins-1234567890abcdef

2. IAM Identity Center からユーザーやグループに権限を作成する
Identity Center から特定のユーザーやグループに S3 Access Grant を作成するには、IAM Identity Center で GUID を見つける必要があります。以下では、IAM Identity Center コンソールでこの値を見つける場所を示しています。例えば、ユーザー「Rafael」の IAM Identity Center での GUID は 83d43802-00b1-7054-db02-f1d683aacba5 です。

図 3: ユーザー ID 付き Identity Center ユーザー情報

IAM Identity Center のユーザーの GUID を見つける別の方法としては、AWS CLI を通じて、または AWS SDK を使用してプログラム的に Identity Store API への API リクエストを行う方法があります。こちらが Identity Store API のドキュメントです。

たとえば、このコマンドは IAM Identity Center のユーザーを名前と識別子と共にリストします。

aws identitystore list-users --identity-store-id d-1a2b3c4d1234

このコマンドはユーザーの GUID を返します。

aws identitystore get-user-id --region us-east-21 --cli-input-json '{ 
"IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { 
"AttributePath": "UserName", "AttributeValue": "rafael" } } }'

このコマンドは IAM Identity Center のグループをリストします。

aws identitystore list-groups --identity-store-id d-1a2b3c4d1234

そして、このコマンドは “TeamA” という名前のグループの GUID を返します。

aws identitystore get-group-id --region us-east-21 --cli-input-json '{ 
"IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { 
"AttributePath": "DisplayName", "AttributeValue": "TeamA" } } }'

IAM Identity Center のディレクトリユーザーとグループに S3 Access Grants 権限を付与することは、IAM プリンシパルへのアクセスを付与することに似ています。付与される対象のタイプは DIRECTORY_USER または DIRECTORY_GROUP で、付与される識別子は IAM Identity Center がユーザーやグループを識別するために使用する GUID になります。

例えば、get-user-id を使用して Rafael の GUID を取得し、以下のコマンドでそのユーザー ID 83d43802-00b1-7054-db02-f1d683aacba5 に DOC-EXAMPLE-BUCKET/rafael/* の範囲でアクセス権を付与します。

aws s3control create-access-grant \
--account-id 123456789012 \
--access-grants-location-id default \
--access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/rafael/*" \
--permission READWRITE \
--grantee GranteeType=DIRECTORY_USER,GranteeIdentifier=83d43802-00b1-7054-db02-f1d683aacba5 \

結論

この投稿では、S3 Access Grants が Amazon S3 へのデータアクセスを拡張する方法について学びました。これらの権限は IAM プリンシパルをサポートするだけでなく、IAM Identity Center と同期された企業ディレクトリのユーザーとグループに直接アクセス権を付与することも可能です。

S3 Access Grants は、IAM ベースの技術よりも柔軟でスケーラブルなメカニズムを提供し、大規模なアクセスパターンを定義できます。IAM Identity Center Trusted Identity Propagation との統合により、認証された各ユーザーの代わりに Amazon S3 のデータにアクセスし、ユーザーを認証するデータアプリケーションを開発することができます。また、最終的なユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに表示されるため、監査が簡素化されます。

S3 Access Grants について詳しく知りたい場合は、ドキュメントをご覧ください。

Rafael Koike

Rafael M. Koike は、サウスイーストのエンタープライズカスタマーをサポートするプリンシパルソリューションアーキテクトであり、Storage TFC の一員です。セキュリティ、ストレージ、ネットワーキング、アプリケーション開発における彼の専門知識は、お客様が安全かつ迅速にクラウドへ移行する際に重要な役割を果たしています。

Vaibhav Sabharwal

Vaibhav Sabharwal は、ニューヨークを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。新しいクラウドテクノロジーの学習に情熱を持ち、クラウド採用戦略の構築、革新的なソリューションの設計、オペレーショナル・エクセレンスの推進を顧客に支援しています。AWS の金融サービス技術分野コミュニティのメンバーとして、業界内の協力的な取り組みに積極的に貢献しています。

この記事は Scaling data access with Amazon S3 Access Grants (記事公開日: 2023 年 11 月 26 日) を翻訳したものです。翻訳は串上が担当しました。