# Amazon DynamoDB のセキュリティとコンプライアンス AWS では、クラウドのセキュリティが最優先事項です。セキュリティを最も重視する組織の要件を満たすために構築された 「AWS」 のデータセンターとネットワークアーキテクチャは、お客様に大きく貢献します。 セキュリティは、「AWS」 と顧客の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、この責任がクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明されています。 + **クラウドのセキュリティ** - AWS は、AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する責任を負います。また、AWS は、使用するサービスを安全に提供します。セキュリティの有効性は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの審査機関によって定期的にテストおよび検証されています。DynamoDB に適用するコンプライアンスプログラムの詳細については、[コンプライアンスプログラムによる対象範囲内の AWS サービス](https://aws.amazon.com/compliance/services-in-scope/)を参照してください。 + **クラウド内のセキュリティ** – お客様の責任は使用する AWS のサービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。 このドキュメントでは、DynamoDB を使用するときに、責任共有モデルを適用する方法を理解できます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために DynamoDB を設定する方法を示します。また、DynamoDB リソースのモニタリングや保護に役立つ他の AWS サービスの用法についても説明します。 **Topics** + [Amazon DynamoDB の AWS マネージドポリシー](ddb-security-iam.awsmanpol.md) + [DynamoDB 用のリソースベースのポリシーを使用する](access-control-resource-based.md) + [DynamoDB での属性ベースのアクセス制御の使用](attribute-based-access-control.md) + [DynamoDB におけるデータ保護](data-protection.md) + [AWS Identity and Access Management (IAM) と DynamoDB](identity-and-access-mgmt.md) + [DynamoDB の業界別のコンプライアンス検証](Compliance.md) + [Amazon DynamoDB での耐障害性と災害対策](disaster-recovery-resiliency.md) + [Amazon DynamoDB のインフラストラクチャセキュリティ](network-isolation.md) + [AWS PrivateLink for DynamoDB](privatelink-interface-endpoints.md) + [Amazon DynamoDB での設定と脆弱性の分析](configuration-vulnerability.md) + [Amazon DynamoDB のセキュリティベストプラクティス](best-practices-security.md) # Amazon DynamoDB の AWS マネージドポリシー DynamoDB は、AWS マネージドポリシーを使用して、サービスが特定のアクションを実行するために必要な一連のアクセス許可を定義します。DynamoDB は、その AWS マネージドポリシーを維持および更新します。AWS マネージドポリシーのアクセス許可を変更することはできません。AWS マネージドポリシーの詳細については、「IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。 DynamoDB は、新しい機能をサポートするために、AWS マネージドポリシーに新しいアクセス許可を追加する場合があります。この種の更新は、ポリシーがアタッチされているすべてのアイデンティティ (ユーザー、グループ、ロール) に影響を与えます。AWS マネージドポリシーは、新しい機能がリリースされたときや新しいオペレーションが使用可能になったときに、更新される可能性が最も高くなります。DynamoDB は AWS マネージドポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が破棄されることはありません。AWS マネージドポリシーの完全なリストについては、「[AWS マネージドポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/policy-list.html)」を参照してください。 ## AWS マネージドポリシー: DynamoDBReplicationServiceRolePolicy `DynamoDBReplicationServiceRolePolicy` ポリシーを IAM エンティティにアタッチすることはできません。このポリシーは、ユーザーに代わってアクションを実行することを DynamoDB に許可する、サービスにリンクされたロールにアタッチします。詳細については、「[グローバルテーブルでの IAM の使用](globaltables-security.md)」を参照してください。 このポリシーは、サービスにリンクされたロールに対して、グローバルテーブルのレプリカ間でデータをレプリケートするアクセス許可を付与します。また、ユーザーに代わってグローバルテーブルのレプリカを管理する管理者アクセス許可も付与します。 **アクセス許可の詳細** このポリシーは、以下を行うアクセス許可を付与します。 + `dynamodb` — データのレプリケーションを実行し、テーブルのレプリカを管理します。 + `application-autoscaling` — テーブルの AutoScaling 設定を取得および管理します。 + `account` — レプリカのアクセシビリティを評価するためのリージョンのステータスを取得します。 + `iam` — サービスリンクロールが現時点で存在しない場合、アプリケーションの AutoScaling 用のサービスリンクロールを作成します。 このマネージドポリシーの定義については、[こちら](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/DynamoDBReplicationServiceRolePolicy.html)を参照してください。 ## AWS マネージドポリシー: AmazonDynamoDBFullAccess\$1v2 スコープダウン `AmazonDynamoDBFullAccess_v2` ポリシーは、ユーザーに特定のアクセス権限を付与します。`AmazonDynamoDBFullAccess_v2` ポリシーを IAM IDにアタッチできます。このポリシーは、Amazon DynamoDB リソースへの管理アクセスを許可し、DynamoDB が統合されている AWS のサービスへのアクセスを IAM ID (ユーザー、グループ、ロールなど) に許可して、DynamoDB のすべての機能を使用できるようにします。このポリシーを使用すると、AWS マネジメントコンソールで利用可能な DynamoDB のすべての機能にアクセスできます。 **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `Amazon DynamoDB` + `DynamoDB Accelerator` + `AWS KMS` + `AWS Resource Groups Tagging` + `Lambda` + `Application Auto Scaling` + `CloudWatch` + `Amazon Kinesis` + `Amazon EC2` + `IAM` `JSON` 形式のポリシーを確認するには、「[AmazonDynamoDBFullAccess\$1v2](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess_v2.html)」を参照してください。 ## AWS 管理ポリシー: AmazonDynamoDBReadOnlyAccess `AmazonDynamoDBReadOnlyAccess` ポリシーを IAM IDにアタッチできます。 このポリシーは Amazon DynamoDB への読み取り専用アクセスを許可します。 **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `Amazon DynamoDB` – Amazon DynamoDB への読み取り専用アクセスを提供します。 + `Amazon DynamoDB Accelerator (DAX)` – Amazon DynamoDB Accelerator (DAX) への読み取り専用アクセスを提供します。 + `Application Auto Scaling` — Application Auto Scaling の設定をプリンシパルが表示できるようにします。これは、テーブルにアタッチされているオートスケーリングポリシーをユーザーが表示できる場合に必須です。 + `CloudWatch` - CloudWatch で設定されたメトリクスデータとアラームをプリンシパルが表示できるようにします。これは、テーブルに対して設定された請求対象テーブルサイズと CloudWatch アラームをユーザーが表示できる場合に必須です。 + `AWS Data Pipeline` — プリンシパルが AWS Data Pipeline と関連オブジェクトを表示することを許可します。 + `Amazon EC2` – プリンシパルが Amazon EC2 VPC、サブネット、およびセキュリティグループを表示することを許可します。 + `IAM` — プリンシパルが IAM ロールを表示することを許可します。 + `AWS KMS` — で設定されたキーをプリンシパルが表示できるようにします。AWS KMSこれは、ユーザーが、各自のアカウントで作成して管理している AWS KMS keys を表示するために必要です。 + `Amazon SNS` – Amazon SNS のトピックとトピック別のサブスクリプションを一覧表示することをプリンシパルに許可します。 + `AWS Resource Groups` — プリンシパルがリソースグループとクエリを表示することを許可します。 + `AWS Resource Groups Tagging` — プリンシパルがリージョン内のタグ付けされたリソースまたは以前にタグ付けされたリソースのすべてを一覧表示することを許可します。 + `Kinesis` — プリンシパルが Kinesis データストリーム記述を表示することを許可します。 + `Amazon CloudWatch Contributor Insights` — プリンシパルが Contributor Insights ルールによって収集された時系列データを表示することを許可します。 ポリシーを `JSON` 形式で確認するには、「[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBReadOnlyAccess.html)」を参照してください。 ## DynamoDB での AWS マネージドポリシーの更新 この表は、DynamoDB の AWS アクセス管理ポリシーの更新を示しています。 **** | 変更 | 説明 | 変更日 | | --- | --- | --- | | AmazonDynamoDBFullAccess - 廃止済み | このポリシーは、`AmazonDynamoDBFullAccess_v2` という名前のスコープダウンポリシーに置き換えられました。 **2025 年 4 月**以降、新しいユーザー、グループ、またはロールに `AmazonDynamoDBFullAccess` ポリシーをアタッチすることはできません。詳細については、「[AWS マネージドポリシー: AmazonDynamoDBFullAccess\$1v2](#ddb-security-iam.awsmanpol.fullaccesspolicy-v2)」を参照してください。 | 2025 年 4 月 28 日 | | AmazonDynamoDBReadOnlyAccess の既存のポリシーに対する更新 | AmazonDynamoDBReadOnlyAccess に dynamodb:GetAbacStatus および dynamodb:UpdateAbacStatus のアクセス許可を追加しました。これらのアクセス許可により、現在のリージョンで AWS アカウントの ABAC ステータスを表示し、ABAC を有効にすることができます。 | 2024 年 11 月 18 日 | | AmazonDynamoDBReadOnlyAccess の既存のポリシーに対する更新 | AmazonDynamoDBReadOnlyAccess にアクセス許可  を追加しました。dynamodb:GetResourcePolicyこのアクセス許可は、DynamoDB リソースにアタッチされたリソースベースのポリシーの読み取りアクセスを提供します。 | 2024 年 3 月 20 日 | | DynamoDBReplicationServiceRolePolicy の既存のポリシーに対する更新 | DynamoDBReplicationServiceRolePolicy にアクセス許可  を追加しました。dynamodb:GetResourcePolicyこのアクセス許可では、サービスリンクロールは、DynamoDB リソースにアタッチされたリソースベースのポリシーを読み取ることができます。 | 2023 年 12 月 15 日 | | DynamoDBReplicationServiceRolePolicy の既存のポリシーに対する更新 | DynamoDBReplicationServiceRolePolicy にアクセス許可 account:ListRegions を追加しました。このアクセス許可は、サービスにリンクされたロールに対して、レプリカのアクセシビリティを評価することを許可します。 | 2023 年 5 月 10 日 | | DynamoDBReplicationServiceRolePolicy をマネージドポリシーのリストに追加 | マネージドポリシー DynamoDBReplicationServiceRolePolicy に関する情報を追加しました。このポリシーは DynamoDB グローバルテーブルのサービスにリンクされたロールで使用されます。 | 2023 年 5 月 10 日 | | DynamoDB グローバルテーブルが変更の追跡を開始 | DynamoDB グローバルテーブルが AWS マネージドポリシーの変更の追跡を開始しました。 | 2023 年 5 月 10 日 | # DynamoDB 用のリソースベースのポリシーを使用する DynamoDB では、テーブル、インデックス、ストリームに対してリソースベースのポリシーを利用できます。リソースベースのポリシーでは、各リソースにアクセスできるユーザーと、各リソースに対して実行できるアクションを指定することで、アクセス許可を定義できます。 リソースベースのポリシーを DynamoDB リソース (テーブルやストリームなど) にアタッチできます。このポリシーでは、Identity and Access Management (IAM) [プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-principal)に対して、該当する DynamoDB リソースで特定のアクションを実行するためのアクセス許可を指定します。例えば、テーブルにアタッチされたポリシーでは、そのテーブルとそのインデックスへのアクセス許可を指定します。そのため、リソースベースのポリシーを使用すれば、リソース単位でアクセス許可を定義することで、DynamoDB のテーブル、インデックス、ストリームへのアクセスを簡単に制御できます。DynamoDB リソースにアタッチできるポリシーの最大サイズは 20 KB です。 リソースベースのポリシーを使用する大きな利点は、さまざまな AWS アカウント で IAM プリンシパルにクロスアカウントアクセスを許可するための、クロスアカウントアクセス制御が簡単になることです。詳細については、「[クロスアカウントアクセスのリソースベースのポリシー](rbac-examples.md#rbac-examples-cross-account)」を参照してください。 リソースベースのポリシーは、[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) の外部アクセスアナライザーや[ブロックパブリックアクセス (BPA)](rbac-bpa-rbp.md) 機能と統合することもできます。IAM Access Analyzer は、リソースベースのポリシーで指定された外部エンティティへのクロスアカウントアクセスについて報告します。また、情報を可視化してくれるので、アクセス許可を調整し、最小特権の原則を守るうえでも役立ちます。BPA では、DynamoDB のテーブル、インデックス、ストリームへのパブリックアクセスを阻止できます。BPA は、リソースベースのポリシーの作成と変更のワークフローで自動的に有効になります。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/q9sBxrVgq4U?si=0cR4TJIlKvH9Wlu5/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/q9sBxrVgq4U?si=0cR4TJIlKvH9Wlu5) **Topics** + [リソースベースのポリシーを指定してテーブルを作成する](rbac-create-table.md) + [DynamoDB の既存のテーブルにポリシーをアタッチする](rbac-attach-resource-based-policy.md) + [リソースベースのポリシーを DynamoDB ストリームにアタッチする](rbac-attach-resource-policy-streams.md) + [リソースベースのポリシーを DynamoDB テーブルから削除する](rbac-delete-resource-based-policy.md) + [DynamoDB でリソースベースのポリシーを使用したクロスアカウントアクセス](rbac-cross-account-access.md) + [DynamoDB でリソースベースのポリシーでパブリックアクセスをブロックする](rbac-bpa-rbp.md) + [リソースベースのポリシーでサポートされる DynamoDB API オペレーション](rbac-iam-actions.md) + [IAM アイデンティティベースのポリシーと DynamoDB リソースベースのポリシーによる認可](rbac-auth-iam-id-based-policies-DDB.md) + [DynamoDB リソースベースのポリシーの例](rbac-examples.md) + [DynamoDB リソースベースのポリシーの考慮事項](rbac-considerations.md) + [DynamoDB リソースベースのポリシーに関するベストプラクティス](rbac-best-practices.md) # リソースベースのポリシーを指定してテーブルを作成する DynamoDB コンソール、[CreateTable API](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html)、AWS CLI、[AWS SDK](rbac-attach-resource-based-policy.md#rbac-attach-policy-java-sdk)、または CloudFormation テンプレートを使用して、テーブルの作成時にリソースベースのポリシーを追加できます。 ## AWS CLI 次の例では、`create-table` AWS CLI コマンドを使用して、*MusicCollection* という名前のテーブルを作成します。このコマンドでは、そのテーブルにリソースベースのポリシーを追加する `resource-policy` パラメータも指定されています。このポリシーは、ユーザー *John* に対して、該当のテーブルで [RestoreTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableToPointInTime.html)、[GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html)、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ``` aws dynamodb create-table \ --table-name MusicCollection \ --attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S \ --key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ --resource-policy \ "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::123456789012:user/John\" }, \"Action\": [ \"dynamodb:RestoreTableToPointInTime\", \"dynamodb:GetItem\", \"dynamodb:DescribeTable\" ], \"Resource\": \"arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection\" } ] }" ``` ## AWS マネジメントコンソール 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. ダッシュボードで、**[テーブルの作成]** を選択します。 1. **[テーブルの詳細]** に、テーブル名、パーティションキー、ソートキーの詳細を入力します。 1. **[テーブル設定]** セクションで **[設定をカスタマイズ]** を選択します。 1. (オプション) **[テーブルクラス]**、**[キャパシティー計算ツール]**、**[読み込み/書き込みキャパシティーの設定]**、**[セカンダリインデックス]**、**[保管時の暗号化]**、**[削除保護]** のオプションを指定します。 1. **[リソースベースのポリシー]** で、テーブルとそのインデックスへのアクセス許可を定義するポリシーを追加します。このポリシーでは、これらのリソースにアクセスできるユーザーと、各リソースに対して実行できるアクションを指定します。ポリシーを追加するには、以下のいずれかを実行します。 + JSON ポリシードキュメントを入力するか貼り付けます。IAM ポリシー言語の詳細については、「IAM ユーザーガイド**」の「[JSON エディターを使用したポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」を参照してください。 **ヒント** 「Amazon DynamoDB デベロッパーガイド」のリソースベースのポリシーの例を確認するには、**[ポリシーの例]** を選択してください。 + **[新しいステートメントを追加]** を選択して新しいステートメントを追加し、提示されたフィールドに情報を入力します。このステップを、追加するステートメントの数だけ繰り返します。 **重要** セキュリティ警告、エラー、提案がある場合は、ポリシーを保存する前に解決してください。 次の IAM ポリシーの例では、ユーザー *John* に対して、テーブル *MusicCollection* で [RestoreTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableToPointInTime.html)、[GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html)、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/username" }, "Action": [ "dynamodb:RestoreTableToPointInTime", "dynamodb:GetItem", "dynamodb:PutItem" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection" } ] } ``` ------ 1. (オプション) 新しいポリシーがリソースへのパブリックアクセスおよびクロスアカウントアクセスにどのように影響するかをプレビューするには、**[外部アクセスをプレビュー]** を選択します。ポリシーを保存する前に、新しい IAM Access Analyzer の結果が導入されているかどうかや、既存の結果を解決するかどうかを確認できます。アクティブなアナライザーが表示されない場合は、**[Access Analyzer へ移動]** を選択し、[[IAM Access Analyzer]](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) でアカウントアナライザーを作成します。詳細については、「[アクセスのプレビュー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)」を参照してください。 1. **[テーブルの作成]** を選択します。 ## AWS CloudFormation テンプレート ------ #### [ Using the AWS::DynamoDB::Table resource ] 次の CloudFormation テンプレートでは、[AWS::DynamoDB::Table](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) リソースを使用して、ストリームを有効にしたテーブルを作成します。このテンプレートでは、該当するテーブルとストリームの両方にアタッチされたリソースベースのポリシーも指定しています。 ``` { "AWSTemplateFormatVersion": "2010-09-09", "Resources": { "MusicCollectionTable": { "Type": "AWS::DynamoDB::Table", "Properties": { "AttributeDefinitions": [ { "AttributeName": "Artist", "AttributeType": "S" } ], "KeySchema": [ { "AttributeName": "Artist", "KeyType": "HASH" } ], "BillingMode": "PROVISIONED", "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 5 }, "StreamSpecification": { "StreamViewType": "OLD_IMAGE", "ResourcePolicy": { "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": "arn:aws:iam::111122223333:user/John" }, "Effect": "Allow", "Action": [ "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:DescribeStream" ], "Resource": "*" } ] } } }, "TableName": "MusicCollection", "ResourcePolicy": { "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/John" ] }, "Effect": "Allow", "Action": "dynamodb:GetItem", "Resource": "*" } ] } } } } } } ``` ------ #### [ Using the AWS::DynamoDB::GlobalTable resource ] 次の CloudFormation テンプレートでは、[AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) リソースを使用してテーブルを作成し、リソースベースのポリシーを該当テーブルとそのストリームにアタッチします。 ``` { "AWSTemplateFormatVersion": "2010-09-09", "Resources": { "GlobalMusicCollection": { "Type": "AWS::DynamoDB::GlobalTable", "Properties": { "TableName": "MusicCollection", "AttributeDefinitions": [{ "AttributeName": "Artist", "AttributeType": "S" }], "KeySchema": [{ "AttributeName": "Artist", "KeyType": "HASH" }], "BillingMode": "PAY_PER_REQUEST", "StreamSpecification": { "StreamViewType": "NEW_AND_OLD_IMAGES" }, "Replicas": [ { "Region": "us-east-1", "ResourcePolicy": { "PolicyDocument": { "Version": "2012-10-17", "Statement": [{ "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/John" ] }, "Effect": "Allow", "Action": "dynamodb:GetItem", "Resource": "*" }] } }, "ReplicaStreamSpecification": { "ResourcePolicy": { "PolicyDocument": { "Version": "2012-10-17", "Statement": [{ "Principal": { "AWS": "arn:aws:iam::111122223333:user/John" }, "Effect": "Allow", "Action": [ "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:DescribeStream" ], "Resource": "*" }] } } } } ] } } } } ``` ------ # DynamoDB の既存のテーブルにポリシーをアタッチする DynamoDB コンソール、[PutResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutResourcePolicy.html) API、AWS CLI、AWS SDK、または [CloudFormation テンプレート](rbac-create-table.md#rbac-create-table-cfn)を使用して、リソースベースのポリシーを既存のテーブルにアタッチしたり、既存のポリシーを変更したりできます。 ## AWS CLI の例: 新しいポリシーをアタッチする 次の IAM ポリシーの例では、`put-resource-policy` AWS CLI コマンドを使用して、リソースベースのポリシーを既存のテーブルにアタッチします。この例では、ユーザー *John* に対して、*MusicCollection* という名前の既存のテーブルで [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html)、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html)、[UpdateItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html)、[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ``` aws dynamodb put-resource-policy \ --resource-arn arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection \ --policy \ "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::111122223333:user/John\" }, \"Action\": [ \"dynamodb:GetItem\", \"dynamodb:PutItem\", \"dynamodb:UpdateItem\", \"dynamodb:UpdateTable\" ], \"Resource\": \"arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection\" } ] }" ``` ## AWS CLI の例: 既存のポリシーを条件に従って更新する テーブルの既存のリソースベースポリシーを条件に従って更新する場合は、オプションの `expected-revision-id` パラメータを使用できます。次の例では、ポリシーが DynamoDB に存在し、現在のリビジョン ID が `expected-revision-id` パラメータに指定された値と一致する場合にのみ、ポリシーを更新します。 ``` aws dynamodb put-resource-policy \ --resource-arn arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection \ --expected-revision-id 1709841168699 \ --policy \ "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::111122223333:user/John\" }, \"Action\": [ \"dynamodb:GetItem\", \"dynamodb:UpdateItem\", \"dynamodb:UpdateTable\" ], \"Resource\": \"arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection\" } ] }" ``` ## AWS マネジメントコンソール 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. ダッシュボードから、既存のテーブルを選択します。 1. **[アクセス許可]** タブに移動し、**[テーブルポリシーを作成]** を選択します。 1. [リソースベースのポリシー] エディターで、アタッチするポリシーを追加し、**[ポリシーを作成]** を選択します。 次の IAM ポリシーの例では、ユーザー *John* に対して、*MusicCollection* という名前の既存のテーブルで [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html)、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html)、[UpdateItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html)、[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/username" }, "Action": [ "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:UpdateTable" ], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection" } ] } ``` ------ ## AWS SDK for Java 2.x 次の IAM ポリシーの例では、`putResourcePolicy` メソッドを使用して、リソースベースのポリシーを既存のテーブルにアタッチしています。このポリシーは、既存のテーブルで [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) API アクションを実行することをユーザーに許可します。 ``` import software.amazon.awssdk.regions.Region; import software.amazon.awssdk.services.dynamodb.DynamoDbClient; import software.amazon.awssdk.services.dynamodb.model.DynamoDbException; import software.amazon.awssdk.services.dynamodb.model.PutResourcePolicyRequest; /** * Before running this Java V2 code example, set up your development * environment, including your credentials. * * For more information, see the following documentation topic: * * [Get started with the AWS SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html) */ public class PutResourcePolicy { public static void main(String[] args) { final String usage = """ Usage: Where: tableArn - The Amazon DynamoDB table ARN to attach the policy to. For example, arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection. allowedAWSPrincipal - Allowed AWS principal ARN that the example policy will give access to. For example, arn:aws:iam::123456789012:user/John. """; if (args.length != 2) { System.out.println(usage); System.exit(1); } String tableArn = args[0]; String allowedAWSPrincipal = args[1]; System.out.println("Attaching a resource-based policy to the Amazon DynamoDB table with ARN " + tableArn); Region region = Region.US_WEST_2; DynamoDbClient ddb = DynamoDbClient.builder() .region(region) .build(); String result = putResourcePolicy(ddb, tableArn, allowedAWSPrincipal); System.out.println("Revision ID for the attached policy is " + result); ddb.close(); } public static String putResourcePolicy(DynamoDbClient ddb, String tableArn, String allowedAWSPrincipal) { String policy = generatePolicy(tableArn, allowedAWSPrincipal); PutResourcePolicyRequest request = PutResourcePolicyRequest.builder() .policy(policy) .resourceArn(tableArn) .build(); try { return ddb.putResourcePolicy(request).revisionId(); } catch (DynamoDbException e) { System.err.println(e.getMessage()); System.exit(1); } return ""; } private static String generatePolicy(String tableArn, String allowedAWSPrincipal) { return "{\n" + " \"Version\": \"2012-10-17\",\n" +, " \"Statement\": [\n" + " {\n" + " \"Effect\": \"Allow\",\n" + " \"Principal\": {\"AWS\":\"" + allowedAWSPrincipal + "\"},\n" + " \"Action\": [\n" + " \"dynamodb:GetItem\"\n" + " ],\n" + " \"Resource\": \"" + tableArn + "\"\n" + " }\n" + " ]\n" + "}"; } } ``` # リソースベースのポリシーを DynamoDB ストリームにアタッチする DynamoDB コンソール、[PutResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutResourcePolicy.html) API、AWS CLI、AWS SDK、または [CloudFormation テンプレート](rbac-create-table.md#rbac-create-table-cfn)を使用して、リソースベースのポリシーを既存のテーブルのストリームにアタッチしたり、既存のポリシーを変更したりできます。 **注記** [CreateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html) API や [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) API で作成中のストリームには、ポリシーをアタッチできません。ただし、テーブルの削除後にポリシーを変更または削除することはできます。また、無効になっているストリームのポリシーは変更または削除できます。 ## AWS CLI 次の IAM ポリシーの例では、`put-resource-policy` AWS CLI コマンドを使用して、*MusicCollection* という名前のテーブルのストリームにリソースベースのポリシーをアタッチしています。この例では、ユーザー *John* に対して、該当ストリームで [GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html)、[GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html)、[DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ``` aws dynamodb put-resource-policy \ --resource-arn arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection/stream/2024-02-12T18:57:26.492 \ --policy \ "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::111122223333:user/John\" }, \"Action\": [ \"dynamodb:GetRecords\", \"dynamodb:GetShardIterator\", \"dynamodb:DescribeStream\" ], \"Resource\": \"arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection/stream/2024-02-12T18:57:26.492\" } ] }" ``` ## AWS マネジメントコンソール 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. DynamoDB コンソールのダッシュボードで **[テーブル]** を選択し、既存のテーブルを選択します。 ストリームが有効になっているテーブルを選択してください。テーブルのストリームを有効にする方法については、「[ストリームの有効化](Streams.md#Streams.Enabling)」を参照してください。 1. **[アクセス許可]** タブを選択します。 1. **[アクティブストリームについてのリソースベースのポリシー]** で、**[ストリームポリシーを作成]** を選択します。 1. **[リソースベースのポリシー]** エディターで、ストリームに対するアクセス許可を定義するポリシーを追加します。このポリシーでは、ストリームにアクセスできるユーザーと、ストリームに対して実行できるアクションを指定します。ポリシーを追加するには、以下のいずれかを実行します。 + JSON ポリシードキュメントを入力するか貼り付けます。IAM ポリシー言語の詳細については、「IAM ユーザーガイド**」の「[JSON エディターを使用したポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」を参照してください。 **ヒント** 「Amazon DynamoDB デベロッパーガイド」のリソースベースのポリシーの例を確認するには、**[ポリシーの例]** を選択してください。 + **[新しいステートメントを追加]** を選択して新しいステートメントを追加し、提示されたフィールドに情報を入力します。このステップを、追加するステートメントの数だけ繰り返します。 **重要** セキュリティ警告、エラー、提案がある場合は、ポリシーを保存する前に解決してください。 1. (オプション) 新しいポリシーがリソースへのパブリックアクセスおよびクロスアカウントアクセスにどのように影響するかをプレビューするには、**[外部アクセスをプレビュー]** を選択します。ポリシーを保存する前に、新しい IAM Access Analyzer の結果が導入されているかどうかや、既存の結果を解決するかどうかを確認できます。アクティブなアナライザーが表示されない場合は、**[Access Analyzer へ移動]** を選択し、[[IAM Access Analyzer]](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) でアカウントアナライザーを作成します。詳細については、「[アクセスのプレビュー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)」を参照してください。 1. [**Create policy**] (ポリシーの作成) を選択します。 次の IAM ポリシーの例では、*MusicCollection* という名前のテーブルのストリームにリソースベースのポリシーをアタッチします。この例では、ユーザー *John* に対して、該当ストリームで [GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html)、[GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html)、[DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html) の API アクションを実行することを許可しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/username" }, "Action": [ "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:DescribeStream" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection/stream/2024-02-12T18:57:26.492" ] } ] } ``` ------ # リソースベースのポリシーを DynamoDB テーブルから削除する DynamoDB コンソール、[DeleteResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteResourcePolicy.html) API、AWS CLI、AWS SDK、または CloudFormation テンプレートを使用して、既存のテーブルからリソースベースのポリシーを削除できます。 ## AWS CLI 次の例では、`delete-resource-policy` AWS CLI コマンドを使用して、*MusicCollection* という名前のテーブルからリソースベースのポリシーを削除しています。 *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ``` aws dynamodb delete-resource-policy \ --resource-arn arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection ``` ## AWS マネジメントコンソール 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. DynamoDB コンソールのダッシュボードで **[テーブル]** を選択し、既存のテーブルを選択します。 1. **[アクセス許可]** を選択します。 1. **[ポリシーを管理]** ドロップダウンから **[ポリシーを削除]** を選択します。 1. **[テーブルについてのリソースベースのポリシーを削除]** ダイアログボックスで、「**confirm**」と入力して削除アクションを確定します。 1. **[削除]** を選択します。 # DynamoDB でリソースベースのポリシーを使用したクロスアカウントアクセス リソースベースのポリシーを使用して、異なる AWS アカウント で利用可能なリソースへのクロスアカウントアクセスを許可できます。リソースベースのポリシーで許可されているクロスアカウントアクセスについては、IAM Access Analyzer が該当リソースと同じ AWS リージョン にある場合は、IAM Access Analyzer で外部アクセスの検出結果としてすべて報告されます。IAM Access Analyzer は、IAM [ポリシーの文法](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html)と[ベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)に照らしてポリシーチェックを行います。これらのチェックにより、機能的でセキュリティのベストプラクティスに準拠したポリシーを作成するのに、役立つ結果と実行可能なレコメンデーションが示されます。IAM Access Analyzer のアクティブな検出結果を [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)の **[アクセス許可]** タブで表示できます。 IAM Access Analyzer を使用したポリシーの検証の詳細については、「IAM ユーザーガイド**」の「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」を参照してください。IAM Access Analyzer によって返される警告、エラー、および提案のリストを表示するには、「[IAM Access Analyzer ポリシーチェックリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html)」を参照してください。 アカウント A のユーザー A に、アカウント B のテーブル B にアクセスするための [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) 権限を付与するには、以下の手順を実行します。 1. `GetItem` アクションの実行権限をユーザー A に付与するリソースベースのポリシーを、テーブル B にアタッチします。 1. テーブル B に対して `GetItem` アクションを実行する権限をユーザー A に付与するアイデンティティベースのポリシーを、ユーザー A にアタッチします。 [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)にある **[外部アクセスをプレビュー]** オプションを使用すると、リソースへのパブリックアクセスとクロスアカウントアクセスに新しいポリシーがどのように影響するかをプレビューできます。ポリシーを保存する前に、新しい IAM Access Analyzer の結果が導入されているかどうかや、既存の結果を解決するかどうかを確認できます。アクティブなアナライザーが表示されない場合は、**[Access Analyzer へ移動]** を選択し、[[IAM Access Analyzer]](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html#access-analyzer-enabling) でアカウントアナライザーを作成します。詳細については、「[アクセスのプレビュー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)」を参照してください。 DynamoDB のデータプレーンとコントロールプレーンの API のテーブル名パラメータには、クロスアカウントのオペレーションをサポートするため、テーブルの完全な Amazon リソースネーム (ARN) を指定できます。完全な ARN ではなくテーブル名パラメータのみを指定した場合、API オペレーションは、リクエスタが属するアカウントの該当テーブルに対して実行されます。クロスアカウントアクセスを使用するポリシーの例については、「[クロスアカウントアクセスのリソースベースのポリシー](rbac-examples.md#rbac-examples-cross-account)」を参照してください。 リソース所有者のアカウントは、別のアカウントのプリンシパルが所有者のアカウントの DynamoDB テーブルに対して読み書きを実行している場合にも課金されます。テーブルにプロビジョンドスループットが指定されている場合、所有者アカウントと他のアカウントのリクエスタからのすべてのリクエストの合計によって、リクエストをスロットリングするか (自動スケーリングが無効な場合)、スケールアップ/スケールダウンするか (自動スケーリングが有効な場合) が決まります。 リクエストは所有者アカウントとリクエスタアカウントの両方の CloudTrail ログに記録されるため、2 つのアカウントはそれぞれ、どちらのアカウントがどのデータにアクセスしたかを追跡できます。 ## クロスアカウントの AWS Lambda 関数を使用したアクセスを共有する **アカウント A の Lambda 関数** 1. [IAM コンソール](https://console.aws.amazon.com/iam/)に移動して、アカウント A のAWS Lambda 関数の [Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)として使用される IAM ロールを作成します。必要な DynamoDB Streams と Lambda 呼び出しアクセス許可を持つマネージド IAM ポリシー `AWSLambdaDynamoDBExecutionRole` を追加します。このポリシーは、アカウント A でユーザーがアクセスする可能性のあるすべての DynamoDB Streams リソースへのアクセスも付与します。 1. [Lambda コンソール](https://console.aws.amazon.com/lambda/)で、DynamoDB ストリーム内のレコードを処理する AWS Lambda 関数を作成し、実行ロールのセットアップ中に、前のステップで作成したロールを選択します。 1. Lambda 関数の実行ロールをアカウント B の DynamoDB Streams の所有者に提供して、クロスアカウント読み取りアクセス用のリソースベースのポリシーを設定します。 1. Lambda 関数のセットアップを完了します。 **アカウント B の DynamoDB ストリーム** 1. Lambda 関数を呼び出すアカウント A からクロスアカウントの Lambda 実行ロールを取得します。 1. アカウント B の Amazon DynamoDB コンソールで、Lambda クロスアカウントトリガーのテーブルを選択します。**[エクスポートおよびストリーム]** タブで、DynamoDB ストリーム ARN を見つけます。DynamoDB Streams のステータスがオンになっていることを確認し、リソースポリシーに必要なフルストリーム ARN を書き留めます。 1. **[アクセス許可]** タブで、**[ストリームポリシーを作成]** ボタンをクリックしてビジュアルポリシーエディタを起動します。**[新しいステートメントを追加]** ボタンをクリックするか、既に存在する場合はポリシーを編集します。 1. アカウント A の Lambda 実行ロールをプリンシパルとして指定するポリシーを作成し、必要な DynamoDB Streams アクションを付与します。`dynamodb:DescribeStream`、`dynamodb:GetRecords`、`dynamodb:GetShardIterator`、`dynamodb:ListShards` アクションを必ず含めてください。DynamoDB Streams のリソースポリシーの例の詳細については、「[DynamoDB リソースベースのポリシーの例](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-examples.html)」を参照してください。 **注記** [コントロールプレーン API](HowItWorks.API.md#HowItWorks.API.ControlPlane) のクロスアカウントアクセスでは、1 秒あたりのトランザクション数 (TPS) の上限が低く、500 リクエストです。 # DynamoDB でリソースベースのポリシーでパブリックアクセスをブロックする [ブロックパブリックアクセス (BPA)](#rbac-bpa-rbp) は、[Amazon Web Services (AWS)](https://aws.amazon.com/) アカウント全体で DynamoDB のテーブル、インデックス、ストリームへのパブリックアクセスを許可するリソースベースのポリシーを特定し、アタッチされないように防ぐ機能です。BPA を使用すると、DynamoDB リソースへのパブリックアクセスを阻止できます。BPA はリソースベースのポリシーの作成時や変更時にチェックを行い、DynamoDB のセキュリティ体制の改善に貢献します。 BPA は[自動推論](https://aws.amazon.com/what-is/automated-reasoning/)を活用して、リソースベースのポリシーで許可されるアクセスを分析し、該当するアクセス許可がリソースベースのポリシーの管理時に見つかった場合は警告します。分析では、リソースベースのポリシーのステートメント、アクション、ポリシーで使用されている条件キーセットをすべてまたいでアクセスを検証します。 **重要** BPA は、DynamoDB リソース (テーブル、インデックス、ストリームなど) に直接アタッチされたリソースベースのポリシーによってパブリックアクセスが許可されることがないように防いで、リソースを保護します。BPA を利用したうえでさらに、次のポリシーを注意深く調べて、パブリックアクセスが許可されていないことを確かめてください。 関連する AWS プリンシパル (IAM ロールなど) にアタッチされているアイデンティティベースのポリシー 関連する AWS リソース (AWS Key Management Service (KMS) キーなど) にアタッチされているリソースベースのポリシー [プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)に `*` エントリを含めないでください。または、指定された条件キーのいずれかでプリンシパルからリソースへのアクセスが制限されていることを確認する必要があります。リソースベースのポリシーが AWS アカウント 全体でテーブル、インデックス、またはストリームへのパブリックアクセスを許可している場合、ポリシー内の指定内容が修正され、非パブリックと判断されない限り、そのポリシーの作成または変更は阻止されます。 `Principal` ブロック内に 1 つ以上のプリンシパルを指定することで、ポリシーを非パブリックにすることができます。次のリソースベースのポリシーの例では、2 つのプリンシパルを指定することで、パブリックアクセスをブロックしています。 ``` { "Effect": "Allow", "Principal": { "AWS": [ "123456789012", "111122223333" ] }, "Action": "dynamodb:*", "Resource": "*" } ``` 特定の条件キーを指定してアクセスを制限するポリシーも、パブリックとは見なされません。リソースベースのポリシーで指定されているプリンシパルを評価するほかに、以下の[信頼できる条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)も、リソースベースのポリシーが付与するアクセスが非パブリックであるという評価の補足に使用できます。 + `aws:PrincipalAccount` + `aws:PrincipalArn` + `aws:PrincipalOrgID` + `aws:PrincipalOrgPaths` + `aws:SourceAccount` + `aws:SourceArn` + `aws:SourceVpc` + `aws:SourceVpce` + `aws:UserId` + `aws:PrincipalServiceName` + `aws:PrincipalServiceNamesList` + `aws:PrincipalIsAWSService` + `aws:Ec2InstanceSourceVpc` + `aws:SourceOrgID` + `aws:SourceOrgPaths` さらに、リソースベースのポリシーが非パブリックとなるには、Amazon リソースネーム (ARN) と文字列キーの値にワイルドカードや変数が含まれていてはいけません。リソースベースのポリシーで `aws:PrincipalIsAWSService` キーが使用されている場合は、キー値を true に設定する必要があります。 次のポリシーでは、指定されたアカウントのユーザー `John` にアクセスが限定されています。この条件により `Principal` が制限されるため、パブリックとは見なされません。 ``` { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "dynamodb:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalArn": "arn:aws:iam::123456789012:user/John" } } } ``` 次の例は非パブリックのリソースベースのポリシーです。`StringEquals` 演算子を使用して `sourceVPC` を制限しています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection", "Condition": { "StringEquals": { "aws:SourceVpc": [ "vpc-91237329" ] } } } ] } ``` ------ # リソースベースのポリシーでサポートされる DynamoDB API オペレーション このトピックでは、リソースベースのポリシーでサポートされる API オペレーションを示します。ただし、クロスアカウントアクセスの場合、リソースベースのポリシーで使用できる DynamoDB API は特定のセットに限られます。リソースベースのポリシーをリソースタイプ (バックアップやインポートなど) にアタッチすることはできません。これらのリソースタイプで動作する API に対応する IAM アクションは、リソースベースのポリシーでサポートされる IAM アクションからは除外されます。テーブル管理者は同一アカウント内で内部テーブル設定を構成するため、[UpdateTimeToLive](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTimeToLive.html) や [DisableKinesisStreamingDestination](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DisableKinesisStreamingDestination.html) などの API は、リソースベースのポリシーによるクロスアカウントアクセスに対応していません。 クロスアカウントアクセスに対応した DynamoDB データプレーン API とコントロールプレーン API では、テーブル名のオーバーロードにも対応しています。そのため、テーブル名の代わりにテーブル ARN を指定することができます。これらの API の `TableName` パラメータにテーブル ARN を指定できます。ただし、これらの API がすべてクロスアカウントアクセスに対応しているわけではありません。 **Topics** + [データプレーンの API オペレーション](#rbac-data-plane-actions) + [PartiQL API オペレーション](#rbac-partiql-actions) + [コントロールプレーンの API オペレーション](#rbac-control-plane-actions) + [バージョン 2019.11.21 (現行) のグローバルテーブルの API オペレーション](#rbac-current-global-table-actions) + [バージョン 2017.11.29 (レガシー) のグローバルテーブルの API オペレーション](#rbac-legacy-global-table-actions) + [タグの API オペレーション](#rbac-tags-actions) + [バックアップと復元の API オペレーション](#rbac-backup-restore-actions) + [継続的バックアップ/復元 (PITR) の API オペレーション](#rbac-continuous-backup-restore-actions) + [寄稿者のインサイトの API オペレーション](#rbac-contributor-insights-actions) + [エクスポートの API オペレーション](#rbac-export-actions) + [インポートの API オペレーション](#rbac-import-actions) + [Amazon Kinesis Data Streams の API オペレーション](#rbac-kinesis-actions) + [リソースベースのポリシーの API オペレーション](#rbac-rbp-actions) + [Time-to-Live の API オペレーション](#rbac-ttl-actions) + [その他の API オペレーション](#rbac-other-actions) + [DynamoDB Streams の API オペレーション](#rbac-ds-actions) ## データプレーンの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[データプレーン](HowItWorks.API.md#HowItWorks.API.DataPlane)の API オペレーションが提供する API レベルのサポートをまとめています。 | データプレーン - テーブル/インデックス API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DeleteItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteItem.html) | あり | はい | | [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) | あり | はい | | [PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) | あり | はい | | [クエリ](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html): | あり | はい | | [Scan](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html) | あり | はい | | [UpdateItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html) | あり | はい | | [TransactGetItems](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html) | あり | はい | | [TransactWriteItems](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html) | あり | はい | | [BatchGetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html) | あり | はい | | [BatchWriteItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchWriteItem.html) | あり | はい | ## PartiQL API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[PartiQL](HowItWorks.API.md#HowItWorks.API.DataPlane.partiql) API オペレーションが提供する API レベルのサポートをまとめています。 | PartiQL API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [BatchExecuteStatement](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchExecuteStatement.html) | はい | なし | | [ExecuteStatement](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExecuteStatement.html) | はい | なし | | [ExecuteTransaction](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExecuteTransaction.html) | はい | なし | ## コントロールプレーンの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[コントロールプレーン](HowItWorks.API.md#HowItWorks.API.ControlPlane)の API オペレーションが提供する API レベルのサポートをまとめています。 | コントロールプレーン - テーブル API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [CreateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html) | いいえ | いいえ | | [DeleteTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteTable.html) | あり | はい | | [DescribeTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html) | あり | はい | | [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) | あり | はい | ## バージョン 2019.11.21 (現行) のグローバルテーブルの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[バージョン 2019.11.21 (現行) のグローバルテーブル](GlobalTables.md)の API オペレーションが提供する API レベルのサポートをまとめています。 | バージョン 2019.11.21 (現行) のグローバルテーブル API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeTableReplicaAutoScaling](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTableReplicaAutoScaling.html) | はい | なし | | [UpdateTableReplicaAutoScaling](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTableReplicaAutoScaling.html) | はい | なし | ## バージョン 2017.11.29 (レガシー) のグローバルテーブルの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[バージョン 2017.11.29 (レガシー) のグローバルテーブル](globaltables.V1.md)の API オペレーションが提供する API レベルのサポートをまとめています。 | バージョン 2017.11.29 (レガシー) のグローバルテーブル API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [CreateGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateGlobalTable.html) | いいえ | いいえ | | [DescribeGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeGlobalTable.html) | いいえ | いいえ | | [DescribeGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeGlobalTableSettings.html) | いいえ | いいえ | | [ListGlobalTables](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListGlobalTables.html) | いいえ | いいえ | | [UpdateGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTable.html) | いいえ | いいえ | | [UpdateGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTableSettings.html) | いいえ | いいえ | ## タグの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[タグ](Tagging.Operations.md)に関連する API オペレーションが提供する API レベルのサポートをまとめています。 | タグの API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [ListTagsOfResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListTagsOfResource.html) | あり | はい | | [TagResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TagResource.html) | あり | はい | | [UntagResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UntagResource.html) | あり | はい | ## バックアップと復元の API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[バックアップと復元](Backup-and-Restore.md)に関連する API オペレーションが提供する API レベルのサポートをまとめています。 | バックアップと復元の API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [CreateBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateBackup.html) | はい | なし | | [DescribeBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeBackup.html) | いいえ | いいえ | | [DeleteBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteBackup.html) | いいえ | いいえ | | [RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html) | いいえ | いいえ | ## 継続的バックアップ/復元 (PITR) の API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[継続的バックアップ/復元 (PITR)](Point-in-time-recovery.md) に関連する API オペレーションが提供する API レベルのサポートをまとめています。 | 継続的バックアップ/復元 (PITR) の API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeContinuousBackups](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeContinuousBackups.html) | はい | なし | | [RestoreTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableToPointInTime.html) | はい | なし | | [UpdateContinuousBackups](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateContinuousBackups.html) | はい | なし | ## 寄稿者のインサイトの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[継続的バックアップ/復元 (PITR)](Point-in-time-recovery.md) に関連する API オペレーションが提供する API レベルのサポートをまとめています。 | 寄稿者のインサイトの API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeContributorInsights](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeContributorInsights.html) | はい | なし | | [ListContributorInsights](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListContributorInsights.html) | いいえ | いいえ | | [UpdateContributorInsights](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateContributorInsights.html) | はい | なし | ## エクスポートの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、エクスポートの API オペレーションが提供する API レベルのサポートをまとめています。 | エクスポート API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeExport](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeExport.html) | いいえ | いいえ | | [ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html) | はい | なし | | [ListExports](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListExports.html) | いいえ | いいえ | ## インポートの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、インポートの API オペレーションが提供する API レベルのサポートをまとめています。 | インポート API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeImport](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeImport.html) | いいえ | いいえ | | [ImportTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ImportTable.html) | いいえ | いいえ | | [ListImports](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListImports.html) | いいえ | いいえ | ## Amazon Kinesis Data Streams の API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、Kinesis Data Streams の API オペレーションが提供する API レベルのサポートをまとめています。 | Kinesis API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeKinesisStreamingDestination](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeKinesisStreamingDestination.html) | はい | なし | | [DisableKinesisStreamingDestination](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DisableKinesisStreamingDestination.html) | はい | なし | | [EnableKinesisStreamingDestination](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_EnableKinesisStreamingDestination.html) | はい | なし | | [UpdateKinesisStreamingDestination](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateKinesisStreamingDestination.html) | はい | なし | ## リソースベースのポリシーの API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、リソースベースのポリシーの API オペレーションが提供する API レベルのサポートをまとめています。 | リソースベースのポリシーの API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [GetResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetResourcePolicy.html) | はい | なし | | [PutResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutResourcePolicy.html) | はい | なし | | [DeleteResourcePolicy](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteResourcePolicy.html) | はい | なし | ## Time-to-Live の API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、[Time to Live](TTL.md) (TTL) の API オペレーションが提供する API レベルのサポートをまとめています。 | TTL API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeTimeToLive](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTimeToLive.html) | はい | なし | | [UpdateTimeToLive](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTimeToLive.html) | はい | なし | ## その他の API オペレーション 次の表は、リソースベースのポリシーとクロスアカウントアクセスに対して、その他の API オペレーションが提供する API レベルのサポートをまとめています。 | その他の API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeLimits](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeLimits.html) | いいえ | いいえ | | [DescribeEndpoint](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeEndpoints.html) | いいえ | いいえ | | [ListBackups](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListBackups.html) | いいえ | いいえ | | [ListTables](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListTables.html) | いいえ | いいえ | ## DynamoDB Streams の API オペレーション 次の表には、リソースベースのポリシーとクロスアカウントアクセスに対する DynamoDB Streams API の API レベルのサポートをまとめています。 | DynamoDB Streams API | リソースベースのポリシーのサポート | クロスアカウントのサポート | | --- | --- | --- | | [DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html) | あり | はい | | [GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html) | あり | はい | | [GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html) | あり | はい | | [ListStreams](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_ListStreams.html) | いいえ | なし | # IAM アイデンティティベースのポリシーと DynamoDB リソースベースのポリシーによる認可 **アイデンティティベースのポリシー**はアイデンティティ (IAM ユーザー、ユーザーグループ、ロールなど) にアタッチされます。これらは、アイデンティティが実行できるアクション、実行対象となるリソース、実行条件を制御する IAM ポリシードキュメントです。アイデンティティベースのポリシーには、[管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)ポリシーまたは[インライン](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)ポリシーがあります。 **リソースベースのポリシー**は、リソース (DynamoDB テーブルなど) にアタッチする IAM ポリシードキュメントです。これらのポリシーでは、そのリソースに対して特定のアクションを実行するために指定されたプリンシパルのアクセス許可を付与するとともに、このアクセス許可が適用される条件を定義します。例えば、DynamoDB テーブルのリソースベースのポリシーには、そのテーブルに関連付けられたインデックスも含まれます。リソースベースのポリシーはインラインポリシーです。マネージド型のリソースベースのポリシーはありません。 これらのポリシーの詳細については、「IAM ユーザーガイド**」の「[アイデンティティベースおよびリソースベースのポリシー」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)を参照してください。 IAM プリンシパルがリソース所有者と同じアカウントに属している場合、そのリソースへのアクセス権限の指定には、リソースベースのポリシーで事足ります。さらに、IAM アイデンティティベースのポリシーをリソースベースのポリシーと併せて用意しておくこともできます。クロスアカウントアクセスの場合は、アイデンティティポリシーとリソースポリシーの両方でアクセスを明示的に許可する必要があります。詳細については、「[DynamoDB でリソースベースのポリシーを使用したクロスアカウントアクセス](rbac-cross-account-access.md)」に記載されています。両タイプのポリシーを併用する場合、「[アカウント内でのリクエストの許可または拒否の決定](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow)」の解説通りにポリシーが評価されます。 **重要** アイデンティティベースのポリシーが DynamoDB テーブルへの無条件アクセス (条件なしの `dynamodb:GetItem` など) を許可する場合、`dynamodb:Attributes` への条件付きアクセスを許可するリソースベースのポリシーは、そのアクセスを制限しません。アイデンティティベースのポリシーの無条件許可が優先され、リソースベースのポリシーの条件は制限として適用されません。特定の属性へのアクセスを制限するには、リソースベースのポリシーの条件付き `Deny` ステートメントのみに依存するのではなく、明示的な `Allow` ステートメントを使用します。 # DynamoDB リソースベースのポリシーの例 リソースベースのポリシーの `Resource` フィールドで ARN を指定した場合は、その ARN がアタッチ先の DynamoDB リソースの ARN と一致する場合にのみ、ポリシーが有効になります。 **注記** *イタリック体*のテキストを、リソース固有の情報に必ず置き換えてください。 ## テーブルのリソースベースのポリシー 次のリソースベースのポリシーは、*MusicCollection* という名前の DynamoDB テーブルにアタッチされています。IAM ユーザーの *John* と *Jane* に対して、*MusicCollection* リソースで [GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) アクションと [BatchGetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html) アクションを実行するアクセス許可を付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "1111", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/username", "arn:aws:iam::111122223333:user/Jane" ] }, "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection" ] } ] } ``` ------ ## ストリームのリソースベースのポリシー 次のリソースベースのポリシーは、`2024-02-12T18:57:26.492` という名前の DynamoDB ストリームにアタッチされています。IAM ユーザーの *John* と *Jane* に対して、`2024-02-12T18:57:26.492` リソースで [GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html)、[GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html)、[DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html) の API アクションを実行するアクセス許可を付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "1111", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/username", "arn:aws:iam::111122223333:user/Jane" ] }, "Action": [ "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:GetShardIterator" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection/stream/2024-02-12T18:57:26.492" ] } ] } ``` ------ ## 指定されたリソースに対するあらゆるアクションの実行権限を付与するリソースベースのポリシー テーブルと、テーブルに関連付けられたすべてのインデックスに対するすべてのアクションの実行をユーザーに許可する場合は、ワイルドカード (\$1) を使用して、テーブルに関連するアクションとリソースを表すことができます。リソースにワイルドカード文字を使用した場合、該当する DynamoDB テーブルとそのすべての関連インデックス (未作成のものも含む) へのアクセスがユーザーに許可されます。例えば、次のポリシーは、ユーザー *John* に対して、*MusicCollection* テーブルとそのすべてのインデックス (今後作成されるインデックスを含む) に対するあらゆるアクションの実行権限を付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "1111", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/role-name" }, "Action": "dynamodb:*", "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection", "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection/index/index-name" ] } ] } ``` ------ ## クロスアカウントアクセスのリソースベースのポリシー クロスアカウントの IAM アイデンティティに対して、DynamoDB リソースへのアクセス権限を指定できます。例えば、信頼できるアカウントのユーザーが、特定の項目とその項目内の特定の属性のみにアクセスするという条件で、テーブルの内容の読み取り権限を取得できるようにする場合が考えられます。次のポリシーでは、信頼できる AWS アカウント ID *111111111111* のユーザー *John* に対して、[GetItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) API を使用してアカウント *123456789012* のテーブルのデータにアクセスすることを許可します。このポリシーでは、プライマリキーが *Jane* の項目のみに該当ユーザーがアクセスして、属性 `Artist` と `SongTitle` のみを取得可能であり、その他の属性は取得できないようになっています。 **重要** `SPECIFIC_ATTRIBUTES` 条件を指定しない場合は、返された項目のすべての属性が表示されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CrossAccountTablePolicy", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:user/John" }, "Action": "dynamodb:GetItem", "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection" ], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": "Jane", "dynamodb:Attributes": [ "Artist", "SongTitle" ] }, "StringEquals": { "dynamodb:Select": "SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ 前述のリソースベースのポリシーに加えて、クロスアカウントアクセスを実現するためには、ユーザー *John* にアタッチしたアイデンティティベースのポリシーでも `GetItem` API アクションを許可する必要があります。以下は、ユーザー *John* にアタッチする必要があるアイデンティティベースのポリシーの例です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CrossAccountIdentityBasedPolicy", "Effect": "Allow", "Action": [ "dynamodb:GetItem" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection" ], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": "Jane", "dynamodb:Attributes": [ "Artist", "SongTitle" ] }, "StringEquals": { "dynamodb:Select": "SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ ユーザー John は、アカウント *123456789012* のテーブル *MusicCollection* にアクセスするため、`table-name` パラメータにテーブル ARN を指定して `GetItem` リクエストを行うことができます。 ``` aws dynamodb get-item \ --table-name arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection \ --key '{"Artist": {"S": "Jane"}' \ --projection-expression 'Artist, SongTitle' \ --return-consumed-capacity TOTAL ``` ## IP アドレス条件を指定したリソースベースのポリシー 条件を適用して、発信元の IP アドレス、仮想プライベートクラウド (VPC)、VPC エンドポイント (VPCE) を制限できます。リクエストの発信元のアドレスに基づいてアクセス許可を指定できます。例えば、特定の IP ソース (企業の VPN エンドポイントなど) がアクセス元である場合に限り、ユーザーに DynamoDB リソースへのアクセスを許可したい場合が考えられます。これらの IP アドレスを `Condition` ステートメントに指定します。 次の例では、ユーザー *John* に対して、発信元 IP が `54.240.143.0/24` および `2001:DB8:1234:5678::/64` である場合に任意の DynamoDB リソースへのアクセスを許可します。 ------ #### [ JSON ] **** ``` { "Id":"PolicyId2", "Version":"2012-10-17", "Statement":[ { "Sid":"AllowIPmix", "Effect":"Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:user/username" }, "Action":"dynamodb:*", "Resource":"*", "Condition": { "IpAddress": { "aws:SourceIp": [ "54.240.143.0/24", "2001:DB8:1234:5678::/64" ] } } } ] } ``` ------ また、発信元が特定の VPC エンドポイント (*vpce-1a2b3c4d* など) 以外である場合に、DynamoDB リソースへのアクセスを一切拒否することもできます。 **重要** IPv6 専用の環境で IP ベースのリソースポリシーを持つ DynamoDB テーブルで DAX を使用する場合は、追加のアクセスルールを設定する必要があります。リソースポリシーがテーブルの IPv4 アドレス空間 `0.0.0.0/0` へのアクセスを制限する場合は、DAX クラスターに関連付けられた IAM ロールのアクセスを許可する必要があります。ポリシーに `ArnNotEquals` 条件を追加して、DAX が DynamoDB テーブルへのアクセスを維持できるようにします。詳細については、「[DAX と IPv6](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.create-cluster.DAX_and_IPV6.html)」を参照してください。 ------ #### [ JSON ] **** ``` { "Id":"PolicyId", "Version":"2012-10-17", "Statement": [ { "Sid": "AccessToSpecificVPCEOnly", "Principal": "*", "Action": "dynamodb:*", "Effect": "Deny", "Resource": "*", "Condition": { "StringNotEquals":{ "aws:sourceVpce":"vpce-1a2b3c4d" } } } ] } ``` ------ ## IAM ロールを使用するリソースベースのポリシー リソースベースのポリシーで IAM サービスロールを指定することもできます。このロールを引き受ける IAM エンティティは、そのロールに指定されているアクションのみを、リソースベースのポリシーで指定されているリソースセットに限定して実行できます。 次の例では、IAM エンティティが *MusicCollection* と *MusicCollection* の DynamoDB リソースですべての DynamoDB アクションを実行することを許可しています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "1111", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/role-name" }, "Action": "dynamodb:*", "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection", "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection/*" ] } ] } ``` ------ # DynamoDB リソースベースのポリシーの考慮事項 DynamoDB リソースに対してリソースベースのポリシーを定義する際には、以下の点を考慮してください。 **一般的な考慮事項** + リソースベースのポリシードキュメントでサポートされる最大サイズは 20 KB です。DynamoDB では、この上限に照らしてポリシーのサイズを計算する際に空白はカウントされません。 + 特定のリソースのポリシーの更新が 2 回目以降の場合、同じリソースに対するそのポリシーの前回の更新が正常に終わってから 15 秒間は更新できません。 + 現時点では、リソースベースのポリシーは既存のストリームにのみアタッチできます。作成中のストリームにポリシーをアタッチすることはできません。 **グローバルテーブルに関する考慮事項** + リソースベースのポリシーは、[グローバルテーブルバージョン 2017.11.29 (レガシー)](globaltables_HowItWorks.md) のレプリカではサポートされていません。 + リソースベースのポリシー内で、グローバルテーブルのデータをレプリケートするアクションが DynamoDB のサービスにリンクされたロール (SLR) に対して拒否されている場合、レプリカの追加または削除はエラーで失敗します。 + [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) リソースでは、スタックの更新を行うリージョン以外のリージョンでは、スタックの更新時にレプリカの作成と、そのレプリカへのリソースベースのポリシーの追加を同時に行うことはできません。 **クロスアカウントに関する考慮事項** + リソースベースのポリシーを使用したクロスアカウントアクセスでは、AWS マネージドキーで暗号化したテーブルはサポートされません。AWS KMS のマネージドポリシーへのクロスアカウントアクセスは許可できないからです。 **CloudFormation に関する考慮事項** + リソースベースのポリシーは[ドリフト検出](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html#)には対応していません。AWS CloudFormation スタックテンプレートの外部でリソースベースのポリシーを更新した場合は、CloudFormation スタックに変更内容を反映させる必要があります。 + リソースベースのポリシーは、アウトオブバンドの変更に対応していません。CloudFormation テンプレートの外部でポリシーを追加、更新、または削除しても、テンプレート内のポリシーに変更がない限り、変更は上書きされません。 例えば、テンプレートに含まれているリソースベースのポリシーを、後からテンプレートの外部で更新したとします。テンプレート内のポリシーを変更しない限り、DynamoDB 内の更新済みポリシーはテンプレート内のポリシーと同期されません。 逆に、テンプレートにリソースベースのポリシーは含まれていないが、テンプレートの外部でポリシーを追加したとします。このポリシーは、テンプレートに追加しない限りは、DynamoDB から削除されることはありません。テンプレートにポリシーを追加してスタックを更新すると、DynamoDB の既存のポリシーが、テンプレートで定義されているポリシーと一致するように更新されます。 # DynamoDB リソースベースのポリシーに関するベストプラクティス このトピックでは、DynamoDB リソースに対するアクセス許可と、それらのリソースに対して実行できるアクションを定義する際のベストプラクティスについて説明します。 ## DynamoDB リソースへのアクセス制御を簡素化する DynamoDB リソースにアクセスする必要がある AWS Identity and Access Management プリンシパルがリソース所有者と同じ AWS アカウント に属している場合、プリンシパルごとに IAM アイデンティティベースポリシーを用意する必要はありません。該当するリソースにリソースベースのポリシーをアタッチすれば十分です。このように構成すれば、アクセス制御が簡単になります。 ## リソースベースのポリシーで DynamoDB リソースを保護する DynamoDB のすべてのテーブルとストリームに対してリソースベースのポリシーを作成し、これらのリソースへのアクセスを制御します。リソースベースのポリシーのおかげで、アクセス許可をリソース単位で一元管理し、DynamoDB のテーブル、インデックス、ストリームへのアクセス制御を簡素化し、管理オーバーヘッドを削減できます。リソースベースのポリシーがテーブルまたはストリームに対して指定されていない場合、そのテーブルやストリームへのアクセスは、IAM プリンシパルに関連付けられたアイデンティティベースのポリシーでアクセスが許可されていない限り、暗黙的に拒否されます。 ## 最小特権アクセス許可を適用する DynamoDB リソースに対するリソースベースのポリシーでアクセス許可を設定するときは、アクションの実行に必要なアクセス許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。その際、ワークロードやユースケースに必要なアクセス許可を検討しながら、大まかなアクセス許可から始めるとよいでしょう。ユースケースが成熟してきたら、最小特権になるように付与する権限を減らしていくことができます。 ## 最小特権ポリシーの生成のためにクロスアカウントアクセスアクティビティを分析する IAM Access Analyzer は、リソースベースのポリシーで指定された外部エンティティへのクロスアカウントアクセスを報告します。また、情報が可視化されるため、アクセス許可を調整し、最小特権の原則を守るうえでも役立ちます。ポリシー生成の詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。 ## IAM Access Analyzer を使用して最小特権ポリシーを生成する タスクの実行に必要なアクセス許可のみを付与するには、AWS CloudTrail にログインしているアクセスアクティビティに基づいてポリシーを生成することができます。IAM Access Analyzer は、ポリシーで使用されるサービスとアクションを分析します。 # DynamoDB での属性ベースのアクセス制御の使用 [属性ベースのアクセス制御 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) は、アイデンティティベースのポリシーまたは他の AWS ポリシー (リソースベースのポリシーや組織の IAM ポリシーなど) の[タグ条件](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.html)に基づいてアクセス許可を定義する認可戦略です。DynamoDB テーブルにタグをアタッチすると、タグベースの条件に対して評価されます。テーブルに関連付けられたインデックスは、テーブルに追加するタグを継承します。DynamoDB テーブルごとに最大 50 個のタグを追加できます。テーブル内のすべてのタグにサポートされる最大サイズは 10 KB です。DynamoDB リソースのタグ付けとタグ付けの制限の詳細については、「[DynamoDB でのタグ付けのリソース](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.Operations.html)」および「[DynamoDB でのタグ付けの制限](Tagging.md#TaggingRestrictions)」を参照してください。 タグを使用して AWS リソースへのアクセスを制御する方法の詳細については、「IAM ユーザーガイド」の以下のトピックを参照してください。 + [ の ABAC とはAWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [タグを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) ABAC を使用すると、チームやアプリケーションに異なるアクセスレベルを適用して、より少ないポリシーで DynamoDB テーブルに対してアクションを実行できます。IAM ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグを指定して、DynamoDB テーブルやインデックスへのアクセスを制御できます。これらの条件により、IAM プリンシパル、ユーザー、またはロールが DynamoDB テーブルとインデックスに対して持つアクセスのレベルが決まります。IAM プリンシパルが DynamoDB へのアクセスリクエストを行うと、リソースと ID のタグは IAM ポリシーのタグ条件に照らして評価されます。その後、タグ条件が満たされた場合にのみポリシーが有効になります。これにより、次のいずれかを効果的に示す IAM ポリシーを作成できます。 + *キーが `X` で値は `Y` であるタグを持つリソースのみをユーザーが管理できるようにします*。 + *キー `X` でタグ付けされたリソースへのすべてのユーザーのアクセスを拒否します*。 例えば、タグのキーと値のペアが `"environment": "staging"` である場合にのみ、ユーザーがテーブルを更新できるようにするポリシーを作成できます。[aws:ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) 条件キーを使用して、そのテーブルにアタッチされているタグに基づいてテーブルへのアクセスを許可または拒否できます。 属性ベースの条件は、ポリシーの作成時、または後で AWS マネジメントコンソール、AWS API、AWS Command Line Interface (AWS CLI)、AWS SDK、または AWS CloudFormation を使用して含めることができます。 次の例では、名前 `environment` と値 `production` を持つタグキーが含まれている場合に、`MusicTable` という名前の付いたテーブルで [UpdateItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html) アクションを許可します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:UpdateItem" ], "Resource": "arn:aws:dynamodb:*:*:table/MusicTable", "Condition": { "StringEquals": { "aws:ResourceTag/environment": "production" } } } ] } ``` ------ **Topics** + [ABAC を使用する理由](#why-use-abac) + [DynamoDB で ABAC を実装するための条件キー](#condition-keys-implement-abac) + [DynamoDB で ABAC を使用する際の考慮事項](#abac-considerations) + [DynamoDB での ABAC の有効化](abac-enable-ddb.md) + [DynamoDB テーブルとインデックスでの ABAC の使用](abac-implementation-ddb-tables.md) + [DynamoDB テーブルとインデックスで ABAC を使用する例](abac-example-use-cases.md) + [DynamoDB テーブルとインデックスに関する一般的な ABAC エラーのトラブルシューティング](abac-troubleshooting.md) ## ABAC を使用する理由 + **ポリシー管理の簡素化:** 異なるポリシーを作成して IAM プリンシパルごとにアクセスレベルを定義する必要がないため、使用するポリシーが少なくなります。 + **スケーラブルなアクセス制御:** ABAC を使用すると、新しい DynamoDB リソースを作成する際のポリシーの更新が必要なくなるため、アクセス制御のスケーリングが容易になります。タグを使用して、リソースのタグと一致するタグを含む IAM プリンシパルへのアクセスを許可できます。新しい IAM プリンシパルまたは DynamoDB リソースをオンボードし、適切なタグを適用して、ポリシーを変更することなく、必要なアクセス許可を自動的に付与できます。 + **きめ細かなアクセス許可管理:** ポリシーの作成時には[最小特権を付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)することがベストプラクティスです。ABAC を使用すると、IAM プリンシパルのタグを作成し、そのタグを使用して IAM プリンシパルのタグと一致する特定のアクションとリソースへのアクセスを付与できます。 + **社内ディレクトリとの整合性:** 社内ディレクトリから既存の従業員属性にタグをマッピングして、アクセス制御ポリシーを組織構造に整合させることができます。 ## DynamoDB で ABAC を実装するための条件キー AWS ポリシーで次の条件キーを使用して、DynamoDB テーブルとインデックスへのアクセスレベルを制御できます。 + [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag): DynamoDB テーブルまたはインデックスのタグのキーと値のペアがポリシーでのタグのキーと値と一致するかどうかに基づいてアクセスを制御します。この条件キーは、既存のテーブルまたはインデックスで動作するすべての API に関連しています。 `dynamodb:ResourceTag` 条件は、リソースにタグをアタッチしていないかのように評価されます。 + [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag): リクエストで渡されたタグのキーと値のペアと、ポリシーで指定したタグのペアを比較できます。この条件キーは、リクエストペイロードの一部としてタグを含む API に関連しています。これらの API には、[CreateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html) と [TagResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TagResource.html) が含まれます。 + [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys): リクエスト内のタグキーをポリシーで指定したキーと比較します。この条件キーは、リクエストペイロードの一部としてタグを含む API に関連しています。これらの API には、`CreateTable`、`TagResource`、`UntagResource` が含まれます。 ## DynamoDB で ABAC を使用する際の考慮事項 DynamoDB テーブルまたはインデックスで ABAC を使用する場合は、次の考慮事項が適用されます。 + DynamoDB Streams では、タグ付けと ABAC はサポートされていません。 + DynamoDB のバックアップでは、タグ付けと ABAC はサポートされていません。バックアップで ABAC を使用するには、[AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) を使用することをお勧めします。 + タグは復元されたテーブルには保持されません。ポリシーでタグベースの条件を使用する前に、復元されたテーブルにタグを追加する必要があります。 # DynamoDB での ABAC の有効化 ほとんどの AWS アカウントでは、ABAC はデフォルトで有効になっています。[DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)を使用して、アカウントで ABAC が有効になっているかどうかを確認できます。これを行うには、必ず [dynamodb:GetAbacStatus](#required-permissions-abac) アクセス許可を持つロールで DynamoDB コンソールを開くようにします。次に、DynamoDB コンソールの **[設定]** ページを開きます。 **[属性ベースのアクセス制御]** カードが表示されない場合、またはカードのステータスが **[オン]** と表示される場合は、アカウントで ABAC が有効になっていることを意味します。ただし、次の図に示すように、ステータスが **[オフ]** の **[属性ベースのアクセス制御]** カードが表示された場合、アカウントで ABAC は有効になっていません。 ## 属性ベースのアクセス制御 – 有効になっていません ![\[[属性ベースのアクセス制御] カードが表示された DynamoDB コンソールの [設定] ページ。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/ddb-console-settings-page.png) ABAC は、アイデンティティベースのポリシーまたは他のポリシーで指定されたタグベースの条件を引き続き監査する必要がある AWS アカウントに対して有効になっていません。アカウントで ABAC が有効になっていない場合、DynamoDB テーブルまたはインデックスを操作することを目的としたポリシーのタグベースの条件は、リソースまたは API リクエストにタグが存在しないかのように評価されます。アカウントで ABAC が有効になっている場合、アカウントのポリシーのタグベースの条件は、テーブルまたは API リクエストにアタッチされたタグを考慮して評価されます。 アカウントの ABAC を有効にするには、[ポリシー監査](#policy-audit-for-abac) セクションの説明に従って、まずポリシーを監査することをお勧めします。次に、IAM ポリシーに [ABAC に必要なアクセス許可](#required-permissions-abac)を含めます。最後に、「[コンソールでの ABAC の有効化](#abac-enable-console)」で説明されているステップを実行して、現在のリージョンでアカウントの ABAC を有効にします。ABAC を有効にした後、オプトインから 7 暦日以内にオプトアウトできます。 **Topics** + [ABAC を有効にする前のポリシーの監査](#policy-audit-for-abac) + [ABAC を有効にするために必要な IAM アクセス許可](#required-permissions-abac) + [コンソールでの ABAC の有効化](#abac-enable-console) ## ABAC を有効にする前のポリシーの監査 アカウントで ABAC を有効にする前に、ポリシーを監査して、アカウント内のポリシーに存在する可能性のあるタグベースの条件が意図したとおりに設定されていることを確認します。ポリシーを監査することで、ABAC が有効になった後に DynamoDB ワークフローで認可が変更されることによる予期しない事態を回避できます。タグを使用した属性ベースの条件の使用例と、ABAC 実装の前後の動作については、「[DynamoDB テーブルとインデックスで ABAC を使用する例ユースケースの例](abac-example-use-cases.md)」を参照してください。 ## ABAC を有効にするために必要な IAM アクセス許可 現在のリージョンでアカウントの ABAC を有効にするには、`dynamodb:UpdateAbacStatus` アクセス許可が必要です。アカウントで ABAC が有効になっているかどうかを確認するには、`dynamodb:GetAbacStatus` アクセス許可も必要です。このアクセス許可を使用すると、任意のリージョンのアカウントの ABAC ステータスを表示できます。DynamoDB コンソールへのアクセスに必要なアクセス許可に加えて、これらの許可が必要です。 次の IAM ポリシーは、現在のリージョンのアカウントで ABAC を有効にし、そのステータスを表示するアクセス許可を付与します。 ``` { "version": "2012-10-17", &TCX5-2025-waiver; "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:UpdateAbacStatus", "dynamodb:GetAbacStatus" ], "Resource": "*" } ] } ``` ## コンソールでの ABAC の有効化 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. 上部のナビゲーションペインで、ABAC を有効にするリージョンを選択します。 1. 左のナビゲーションペインで、**[設定]** を選択します。 1. **[Settings]** (設定) ページで、以下の操作を行います。 1. **[属性ベースのアクセス制御]** カードで、**[有効化]** を選択します。 1. **[属性ベースのアクセス制御設定の確認]** ボックスで、**[有効化]** を選択して選択を確定します。 これにより、現在のリージョンの ABAC が有効になり、**[属性ベースのアクセス制御]** カードに **[オン]** のステータスが表示されます。 コンソールで ABAC を有効にした後にオプトアウトする場合は、オプトインから 7 暦日以内にオプトアウトできます。オプトアウトするには、**[設定]** ページの **[属性ベースのアクセス制御]** カードで **[無効化]** を選択します。 **注記** ABAC のステータスの更新は非同期オペレーションです。ポリシーのタグがすぐに評価されない場合は、しばらく待つ必要がある場合があります。変更の適用は最終的に整合します。 # DynamoDB テーブルとインデックスでの ABAC の使用 次の手順は、ABAC を使用してアクセス許可を設定する方法を示しています。このシナリオ例では、DynamoDB テーブルにタグを追加し、タグベースの条件を含むポリシーを使用して IAM ロールを作成します。次に、タグ条件を一致させて、DynamoDB テーブルに対して許可されているアクセス許可をテストします。 **Topics** + [ステップ 1: DynamoDB テーブルにタグを追加](#abac-add-table-tags) + [ステップ 2: タグベースの条件を含むポリシーを使用して IAM ロールを作成](#abac-create-iam-role) + [ステップ 3: 許可されたアクセス許可をテスト](#abac-test-permissions) ## ステップ 1: DynamoDB テーブルにタグを追加 AWS マネジメントコンソール、AWS API、AWS Command Line Interface (AWS CLI)、AWS SDK、または AWS CloudFormation を使用して、新規または既存の DynamoDB テーブルにタグを追加できます。例えば、次の [tag-resource](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/tag-resource.html) CLI コマンドは、`MusicTable` という名前のテーブルにタグを追加します。 ``` aws dynamodb tag-resource —resource-arn arn:aws:dynamodb:us-east-1:123456789012:table/MusicTable —tags Key=environment,Value=staging ``` ## ステップ 2: タグベースの条件を含むポリシーを使用して IAM ロールを作成 [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) 条件キーを使用して [IAM ポリシーを作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)し、IAM ポリシーで指定されたタグのキーと値のペアを、テーブルにアタッチされたキーと値のペアと比較します。次のポリシー例では、これらのテーブルにタグのキーと値のペア `"environment": "staging"` が含まれている場合、ユーザーがテーブルに項目を配置または更新することを許可します。テーブルに指定されたタグのキーと値のペアがない場合、これらのアクションは拒否されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:ResourceTag/environment": "staging" } } } ] } ``` ------ ## ステップ 3: 許可されたアクセス許可をテスト 1. IAM ポリシーを AWS アカウントのテストユーザーまたはロールにアタッチします。使用する IAM プリンシパルが、別のポリシーで DynamoDB テーブルに既にアクセスしていないことを確認します。 1. DynamoDB テーブルに、値が `"staging"` の `"environment"` タグキーが含まれていることを確認します。 1. タグ付きテーブルで `dynamodb:PutItem` および `dynamodb:UpdateItem` アクションを実行します。`"environment": "staging"` タグのキーと値のペアが存在する場合、これらのアクションは成功します。 `"environment": "staging"` タグのキーと値のペアがないテーブルでこれらのアクションを実行すると、リクエストは `AccessDeniedException` で失敗します。 次のセクションで説明する他の[サンプルユースケース](abac-example-use-cases.md)を確認して、ABAC を実装し、さらにテストを実行することもできます。 # DynamoDB テーブルとインデックスで ABAC を使用する例 次の例は、タグを使用して属性ベースの条件を実装するいくつかのユースケースを示しています。 **Topics** + [例 1: aws:ResourceTag を使用してアクションを許可](#abac-allow-example-resource-tag) + [例 2: aws:RequestTag を使用してアクションを許可](#abac-allow-example-request-tag) + [例 3: aws:TagKeys を使用してアクションを拒否](#abac-deny-example-tag-key) ## 例 1: aws:ResourceTag を使用してアクションを許可 `aws:ResourceTag/tag-key` 条件キーを使用して、IAM ポリシーで指定されたタグのキーと値のペアを、DynamoDB テーブルにアタッチされているキーと値のペアと比較できます。例えば、タグ条件が IAM ポリシーとテーブルで一致する場合、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) などの特定のアクションを許可できます。これを作成するには、次のステップを実行します。 ------ #### [ Using the AWS CLI ] 1. テーブルを作成します。次の例では、[create-table](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/create-table.html) AWS CLI コマンドを使用して、`myMusicTable` という名前のテーブルを作成します。 ``` aws dynamodb create-table \ --table-name myMusicTable \ --attribute-definitions AttributeName=id,AttributeType=S \ --key-schema AttributeName=id,KeyType=HASH \ --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ --region us-east-1 ``` 1. このテーブルにタグを追加します。次の [tag-resource](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/tag-resource.html) AWS CLI コマンドの例では、タグのキーと値のペア `Title: ProductManager` を `myMusicTable` に追加します。 ``` aws dynamodb tag-resource --region us-east-1 --resource-arn arn:aws:dynamodb:us-east-1:123456789012:table/myMusicTable --tags Key=Title,Value=ProductManager ``` 1. 次の例に示すように、[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)を作成し、[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBReadOnlyAccess.html) AWS マネージドポリシーがアタッチされたロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:ResourceTag/Title": "ProductManager" } } } ] } ``` ------ このポリシーは、テーブルにアタッチされたタグキーと値がポリシーで指定されたタグと一致する場合に、テーブルに対する `PutItem` アクションを許可します。 1. ステップ 3 で説明したポリシーを使用してロールを引き受けます。 1. [put-item](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/put-item.html) AWS CLI コマンドを使用して、項目を `myMusicTable` に配置します。 ``` aws dynamodb put-item \ --table-name myMusicTable --region us-east-1 \ --item '{ "id": {"S": "2023"}, "title": {"S": "Happy Day"}, "info": {"M": { "rating": {"N": "9"}, "Artists": {"L": [{"S": "Acme Band"}, {"S": "No One You Know"}]}, "release_date": {"S": "2023-07-21"} }} }' ``` 1. テーブルをスキャンして、項目がテーブルに追加されたかどうかを確認します。 ``` aws dynamodb scan --table-name myMusicTable --region us-east-1 ``` ------ #### [ Using the AWS SDK for Java 2.x ] 1. テーブルを作成します。次の例では、[CreateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html) API を使用して `myMusicTable` という名前のテーブルを作成します。 ``` DynamoDbClient dynamoDB = DynamoDbClient.builder().region(region).build(); CreateTableRequest createTableRequest = CreateTableRequest.builder() .attributeDefinitions( Arrays.asList( AttributeDefinition.builder() .attributeName("id") .attributeType(ScalarAttributeType.S) .build() ) ) .keySchema( Arrays.asList( KeySchemaElement.builder() .attributeName("id") .keyType(KeyType.HASH) .build() ) ) .provisionedThroughput(ProvisionedThroughput.builder() .readCapacityUnits(5L) .writeCapacityUnits(5L) .build() ) .tableName("myMusicTable") .build(); CreateTableResponse createTableResponse = dynamoDB.createTable(createTableRequest); String tableArn = createTableResponse.tableDescription().tableArn(); String tableName = createTableResponse.tableDescription().tableName(); ``` 1. このテーブルにタグを追加します。次の例の [TagResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TagResource.html) API は、タグのキーと値のペア `Title: ProductManager` を `myMusicTable` に追加します。 ``` TagResourceRequest tagResourceRequest = TagResourceRequest.builder() .resourceArn(tableArn) .tags( Arrays.asList( Tag.builder() .key("Title") .value("ProductManager") .build() ) ) .build(); dynamoDB.tagResource(tagResourceRequest); ``` 1. 次の例に示すように、[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)を作成し、[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBReadOnlyAccess.html) AWS マネージドポリシーがアタッチされたロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:ResourceTag/Title": "ProductManager" } } } ] } ``` ------ このポリシーは、テーブルにアタッチされたタグキーと値がポリシーで指定されたタグと一致する場合に、テーブルに対する `PutItem` アクションを許可します。 1. ステップ 3 で説明したポリシーを使用してロールを引き受けます。 1. [PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) API を使用して、項目を `myMusicTable` に配置します。 ``` HashMap info = new HashMap<>(); info.put("rating", AttributeValue.builder().s("9").build()); info.put("artists", AttributeValue.builder().ss(List.of("Acme Band","No One You Know").build()); info.put("release_date", AttributeValue.builder().s("2023-07-21").build()); HashMap itemValues = new HashMap<>(); itemValues.put("id", AttributeValue.builder().s("2023").build()); itemValues.put("title", AttributeValue.builder().s("Happy Day").build()); itemValues.put("info", AttributeValue.builder().m(info).build()); PutItemRequest putItemRequest = PutItemRequest.builder() .tableName(tableName) .item(itemValues) .build(); dynamoDB.putItem(putItemRequest); ``` 1. テーブルをスキャンして、項目がテーブルに追加されたかどうかを確認します。 ``` ScanRequest scanRequest = ScanRequest.builder() .tableName(tableName) .build(); ScanResponse scanResponse = dynamoDB.scan(scanRequest); ``` ------ #### [ Using the AWS SDK for Python (Boto3) ] 1. テーブルを作成します。次の例では、[CreateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html) API を使用して `myMusicTable` という名前のテーブルを作成します。 ``` create_table_response = ddb_client.create_table( AttributeDefinitions=[ { 'AttributeName': 'id', 'AttributeType': 'S' }, ], TableName='myMusicTable', KeySchema=[ { 'AttributeName': 'id', 'KeyType': 'HASH' }, ], ProvisionedThroughput={ 'ReadCapacityUnits': 5, 'WriteCapacityUnits': 5 }, ) table_arn = create_table_response['TableDescription']['TableArn'] ``` 1. このテーブルにタグを追加します。次の例の [TagResource](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TagResource.html) API は、タグのキーと値のペア `Title: ProductManager` を `myMusicTable` に追加します。 ``` tag_resouce_response = ddb_client.tag_resource( ResourceArn=table_arn, Tags=[ { 'Key': 'Title', 'Value': 'ProductManager' }, ] ) ``` 1. 次の例に示すように、[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)を作成し、[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBReadOnlyAccess.html) AWS マネージドポリシーがアタッチされたロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:ResourceTag/Title": "ProductManager" } } } ] } ``` ------ このポリシーは、テーブルにアタッチされたタグキーと値がポリシーで指定されたタグと一致する場合に、テーブルに対する `PutItem` アクションを許可します。 1. ステップ 3 で説明したポリシーを使用してロールを引き受けます。 1. [PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) API を使用して、項目を `myMusicTable` に配置します。 ``` put_item_response = client.put_item( TableName = 'myMusicTable' Item = { 'id': '2023', 'title': 'Happy Day', 'info': { 'rating': '9', 'artists': ['Acme Band','No One You Know'], 'release_date': '2023-07-21' } } ) ``` 1. テーブルをスキャンして、項目がテーブルに追加されたかどうかを確認します。 ``` scan_response = client.scan( TableName='myMusicTable' ) ``` ------ **ABAC がない場合** AWS アカウント で ABAC が有効になっていない場合、IAM ポリシーと DynamoDB テーブルのタグ条件が一致しません。結果として、`AmazonDynamoDBReadOnlyAccess` ポリシーの影響により、`PutItem` アクションは `AccessDeniedException` を返します。 ``` An error occurred (AccessDeniedException) when calling the PutItem operation: User: arn:aws:sts::123456789012:assumed-role/DynamoDBReadOnlyAccess/Alice is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:us-east-1:123456789012:table/myMusicTable because no identity-based policy allows the dynamodb:PutItem action. ``` **ABAC がある場合** AWS アカウントで ABAC が有効になっている場合、`put-item` アクションは正常に完了し、テーブルに新しい項目を追加します。これは、IAM ポリシーとテーブルのタグ条件が一致すると、テーブルのインラインポリシーで `PutItem` アクションが許可されるためです。 ## 例 2: aws:RequestTag を使用してアクションを許可 [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) 条件キーを使用すると、リクエストで渡されたタグのキーと値のペアを、IAM ポリシーで指定されたタグペアと比較できます。例えば、タグ条件が一致しない場合は、`aws:RequestTag` を使用して `CreateTable` などの特定のアクションを許可できます。これを作成するには、次のステップを実行します。 ------ #### [ Using the AWS CLI ] 1. 次の例に示すように、[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)を作成し、[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ReadOnlyAccess.html) AWS マネージドポリシーがアタッチされたロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:TagResource" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:RequestTag/Owner": "John" } } } ] } ``` ------ 1. `"Owner": "John"` のタグのキーと値のペアを含むテーブルを作成します。 ``` aws dynamodb create-table \ --attribute-definitions AttributeName=ID,AttributeType=S \ --key-schema AttributeName=ID,KeyType=HASH \ --provisioned-throughput ReadCapacityUnits=1000,WriteCapacityUnits=500 \ --region us-east-1 \ --tags Key=Owner,Value=John \ --table-name myMusicTable ``` ------ #### [ Using the AWS SDK for Python (Boto3) ] 1. 次の例に示すように、[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)を作成し、[AmazonDynamoDBReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBReadOnlyAccess.html) AWS マネージドポリシーがアタッチされたロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:TagResource" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:RequestTag/Owner": "John" } } } ] } ``` ------ 1. `"Owner": "John"` のタグのキーと値のペアを含むテーブルを作成します。 ``` ddb_client = boto3.client('dynamodb') create_table_response = ddb_client.create_table( AttributeDefinitions=[ { 'AttributeName': 'id', 'AttributeType': 'S' }, ], TableName='myMusicTable', KeySchema=[ { 'AttributeName': 'id', 'KeyType': 'HASH' }, ], ProvisionedThroughput={ 'ReadCapacityUnits': 1000, 'WriteCapacityUnits': 500 }, Tags=[ { 'Key': 'Owner', 'Value': 'John' }, ], ) ``` ------ **ABAC がない場合** AWS アカウントで ABAC が有効になっていない場合、インラインポリシーと DynamoDB テーブルのタグ条件が一致しません。結果として、`CreateTable` リクエストは失敗し、テーブルは作成されません。 ``` An error occurred (AccessDeniedException) when calling the CreateTable operation: User: arn:aws:sts::123456789012:assumed-role/Admin/John is not authorized to perform: dynamodb:CreateTable on resource: arn:aws:dynamodb:us-east-1:123456789012:table/myMusicTable because no identity-based policy allows the dynamodb:CreateTable action. ``` **ABAC がある場合** AWS アカウントで ABAC が有効になっている場合、テーブル作成リクエストは正常に完了します。`"Owner": "John"` のタグのキーと値のペアが `CreateTable` リクエスト内に存在するため、インラインポリシーはユーザー `John` が `CreateTable` アクションを実行することを許可します。 ## 例 3: aws:TagKeys を使用してアクションを拒否 [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) 条件キーを使用すると、リクエスト内のタグキーを IAM ポリシーで指定されたキーと比較できます。例えば、リクエストに特定のタグキーが存在*しない*場合、`aws:TagKeys` を使用して `CreateTable` などの特定のアクションを拒否できます。これを作成するには、次のステップを実行します。 ------ #### [ Using the AWS CLI ] 1. 次の例に示すように、[AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) AWS 管理ポリシーがアタッチされているロールに[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "dynamodb:CreateTable", "dynamodb:TagResource" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "Null": { "aws:TagKeys": "false" }, "ForAllValues:StringNotEquals": { "aws:TagKeys": "CostCenter" } } } ] } ``` ------ 1. ポリシーがアタッチされたロールを引き受け、タグキー `Title` を使用してテーブルを作成します。 ``` aws dynamodb create-table \ --attribute-definitions AttributeName=ID,AttributeType=S \ --key-schema AttributeName=ID,KeyType=HASH \ --provisioned-throughput ReadCapacityUnits=1000,WriteCapacityUnits=500 \ --region us-east-1 \ --tags Key=Title,Value=ProductManager \ --table-name myMusicTable ``` ------ #### [ Using the AWS SDK for Python (Boto3) ] 1. 次の例に示すように、[AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) AWS 管理ポリシーがアタッチされているロールに[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "dynamodb:CreateTable", "dynamodb:TagResource" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "Null": { "aws:TagKeys": "false" }, "ForAllValues:StringNotEquals": { "aws:TagKeys": "CostCenter" } } } ] } ``` ------ 1. ポリシーがアタッチされたロールを引き受け、タグキー `Title` を使用してテーブルを作成します。 ``` ddb_client = boto3.client('dynamodb') create_table_response = ddb_client.create_table( AttributeDefinitions=[ { 'AttributeName': 'id', 'AttributeType': 'S' }, ], TableName='myMusicTable', KeySchema=[ { 'AttributeName': 'id', 'KeyType': 'HASH' }, ], ProvisionedThroughput={ 'ReadCapacityUnits': 1000, 'WriteCapacityUnits': 500 }, Tags=[ { 'Key': 'Title', 'Value': 'ProductManager' }, ], ) ``` ------ **ABAC がない場合** AWS アカウントで ABAC が有効になっていない場合、DynamoDB は `create-table` コマンドのタグキーを IAM に送信しません。`Null` 条件は、リクエストにタグがない場合に条件が `false` と評価されることを保証します。`Deny` ポリシーが一致しないため、`create-table` コマンドは正常に完了します。 **ABAC がある場合** AWS アカウントで ABAC が有効になっている場合、`create-table` コマンドで渡されたタグキーは IAM に渡されます。タグキー `Title` は、`Deny` ポリシーに存在する条件ベースのタグキー `CostCenter` に照らして評価されます。`StringNotEquals` 演算子のため、タグキー `Title` は `Deny` ポリシーに存在するタグキーと一致しません。そのため、`CreateTable` アクションは失敗し、テーブルは作成されません。`create-table` コマンドを実行すると、`AccessDeniedException` が返されます。 ``` An error occurred (AccessDeniedException) when calling the CreateTable operation: User: arn:aws:sts::123456789012:assumed-role/DynamoFullAccessRole/ProductManager is not authorized to perform: dynamodb:CreateTable on resource: arn:aws:dynamodb:us-east-1:123456789012:table/myMusicTable with an explicit deny in an identity-based policy. ``` # DynamoDB テーブルとインデックスに関する一般的な ABAC エラーのトラブルシューティング このトピックでは、DynamoDB テーブルまたはインデックスに ABAC を実装する際に発生する可能性がある一般的なエラーや問題のトラブルシューティングに関するアドバイスを提供します。 ## ポリシー内のサービス固有の条件キーによりエラーが発生する サービス固有の条件キーは、有効な条件キーとは見なされません。ポリシーでこのようなキーを使用した場合、エラーが発生します。この問題を解決するには、サービス固有の条件キーを [DynamoDB に ABAC を実装する適切な条件キー](attribute-based-access-control.md#condition-keys-implement-abac)に置き換える必要があります。 例えば、[PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) リクエストを実行する[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#inline-policies)で `dynamodb:ResourceTag` 条件キーを使用したとします。リクエストが `AccessDeniedException` で失敗するとします。次の例は、`dynamodb:ResourceTag` 条件キーを使用した誤りのあるインラインポリシーを示しています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:PutItem" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "dynamodb:ResourceTag/Owner": "John" } } } ] } ``` ------ この問題を解決するには、次の例に示すように、`dynamodb:ResourceTag` 条件キーを `aws:ResourceTag` に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:PutItem" ], "Resource": "arn:aws:dynamodb:*:*:table/*", "Condition": { "StringEquals": { "aws:ResourceTag/Owner": "John" } } } ] } ``` ------ ## ABAC をオプトアウトできない サポート を通じてアカウントで ABAC が有効になっている場合、DynamoDB コンソールから ABAC をオプトアウトすることはできません。オプトアウトするには、[サポート](https://console.aws.amazon.com/support) に問い合わせてください。 次の条件を満たす場合*のみ*、ABAC をオプトアウトできます。 + [DynamoDB コンソールを通じてセルフサービスでオプトイン](abac-enable-ddb.md#abac-enable-console)する方法を使用しました。 + オプトインから 7 暦日以内にオプトアウトします。 # DynamoDB におけるデータ保護 Amazon DynamoDB は、ミッションクリティカルで重要なデータストレージのために設計された、高い耐久性を備えたストレージインフラストラクチャです。冗長性を確保するために、データは、同一の Amazon DynamoDB リージョン内の複数の施設に分散した複数のデバイスに保存されます。 DynamoDB では、ユーザーデータは保管時に保護されるほか、オンプレミスのクライアントと DynamoDB 間の転送中のデータ、DynamoDB と同じ AWS リージョン内のその他の AWS リソース間の転送中のデータも保護されます。 **Topics** + [保管時の DynamoDB 暗号化](EncryptionAtRest.md) + [VPC エンドポイントと IAM ポリシーを使用した DynamoDB 接続の保護](inter-network-traffic-privacy.md) # 保管時の DynamoDB 暗号化 Amazon DynamoDB に保存されているすべてのユーザーデータは、保管時に完全に暗号化されます。DynamoDB の保管時の暗号化は、[AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) に保存されている暗号化キーを使用してすべての保管中のデータを暗号化することにより高度なセキュリティを提供します。この機能は、機密データの保護における負担と複雑な作業を減らすのに役立ちます。保管時に暗号化することで、セキュリティを重視したアプリケーションを構築して、暗号化のコンプライアンスと規制の厳格な要件を満たすことができます。 DynamoDB の保管時の暗号化は、データを堅牢なメディアに保存されている場合は常に暗号化されたテーブル内にデータを配置して保護することにより、プライマリキー、ローカルおよびグローバルセカンダリインデックス、ストリーム、グローバルテーブル、バックアップ、DynamoDB Accelerator (DAX) クラスターなどに対する追加のデータ保護レイヤーを提供します。組織のポリシー、業界や政府の規制、またはコンプライアンス要件によって、アプリケーションのデータセキュリティを高めるために保管時の暗号化の使用が求められることがあります。データベースアプリケーションの暗号化の詳細については、「What is the AWS Database Encryption SDK?」を参照してください。[https://docs.aws.amazon.com/database-encryption-sdk/latest/devguide/what-is-database-encryption-sdk.html](https://docs.aws.amazon.com/database-encryption-sdk/latest/devguide/what-is-database-encryption-sdk.html) 保管時の暗号化には、テーブルの暗号化に使用される暗号化キーを管理するための AWS KMS が統合されます。キーの種類と詳細については、「**AWS Key Management Service 開発者ガイド」の「[AWS Key Management Service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/key-state.html#key-state-cmk-type)」を参照してください。 新しいテーブルを作成する場合、以下のいずれかの AWS KMS key の種類を選択してテーブルを暗号化できます。キーの種類は、いつでも切り替えることができます。 + **AWS 所有のキー –** デフォルトの暗号化タイプ。キーは DynamoDB により所有されます (追加料金なし)。 + **AWS マネージドキー –** キーはアカウントに保存され、AWS KMS によって管理されます (AWS KMS の料金が適用されます)。 + **カスタマーマネージド型キー –** キーはお客様のアカウントに保存され、ユーザーが作成、所有、管理します。ユーザーには KMS キーに対するフルコントロールの権限があります (AWS KMS の料金が適用されます)。 キーの種類の詳細については、「[ Customer keys and AWS keys](/kms/latest/developerguide/concepts.html#key-mgmt)」を参照してください。 **注記** 保存時の暗号化を有効にして新しい DAX クラスターを作成する場合、AWS マネージドキー を使用して、クラスター内の保管中のデータを暗号化します。 テーブルにソートキーが存在する場合、範囲の境界線を示すソートキーの一部が、プレーンテキスト形式でテーブルメタデータに保存されます。 暗号化されたテーブルにアクセスすると、DynamoDB はテーブルデータを透過的に復号化します。暗号化されたテーブルの使用あるいは管理のためにコードやアプリケーションを変更する必要はありません。DynamoDB は、期待される 1 桁ミリ秒のレイテンシーを継続的に提供し、すべての DynamoDB クエリは暗号化されたデータでシームレスに機能します。 新しいテーブルを作成する際に暗号化キーを指定したり、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、Amazon DynamoDB API を使用して既存のテーブルで暗号化キーを切り替えたりすることができます。この方法については、「[DynamoDB での暗号化テーブルの管理](encryption.tutorial.md)」を参照してください。 AWS 所有のキー を使用した保管時の暗号化に追加の料金はかかりません。ただし、AWS KMS 料金が AWS マネージドキー およびカスタマーマネージドキーに適用されます。料金の詳細については、「[AWS KMS の料金](https://aws.amazon.com/kms/pricing)」を参照してください。 DynamoDB の保管時の暗号化は、AWS 中国 (北京)、AWS 中国 (寧夏)、AWS GovCloud (米国) のリージョンを含むすべての AWS リージョンで利用できます。詳細については、「[保管時の DynamoDB 暗号化: 仕組み](encryption.howitworks.md)」および「[DynamoDB の保管時の暗号化の使用に関する注意事項](encryption.usagenotes.md)」を参照してください。 # 保管時の DynamoDB 暗号化: 仕組み Amazon DynamoDB の保管時の暗号化では、256 ビットの Advanced Encryption Standard (AES-256) を使用してデータの暗号化が行われるので、基盤となるストレージへの不正アクセスからデータを保護できます。 保管データ暗号化には、テーブルの暗号化に使用される暗号化キーを管理するための AWS Key Management Service (AWS KMS) が統合されます。 **注記** 2022 年 5 月、AWS KMS は AWS マネージドキー のローテーションスケジュールを 3 年 (約 1,095 日間隔) ごとから毎年 (約 365 日間隔) に変更しました。 新しい AWS マネージドキーは、作成日から 1 年後に自動的にローテーションされ、それ以降はほぼ 1 年ごとにローテーションされます。 既存の AWS マネージドキー は、直近のローテーションから 1 年後にローテーションされ、その後毎年ローテーションされます。 ## AWS 所有のキー AWS 所有のキー はお客様の AWS アカウントに保存されません。これらは、複数の AWS アカウントで使用するために AWS が所有および管理している KMS キーのコレクションの一部です。AWS のサービスでは、データの保護に AWS 所有のキー を使用できます。DynamoDB で使用する AWS 所有のキーは毎年 (約 365 日ごとに) ローテーションされます。 AWS 所有のキー は表示、管理、使用することはできず、その使用を監視することもできません。ただし、データを暗号化するキーを保護するための作業やプログラムを操作したり変更したりする必要はありません。 AWS 所有のキー のご利用に関しては、月額料金や使用料金は請求されません。また、アカウントの AWS KMS クォータにも影響しません。 ## AWS マネージドキー AWS マネージドキー は、お客様のアカウントにある KMS キーであり、AWS KMS と統合されている AWS のサービスがお客様に代わって作成、管理、使用します。アカウントで AWS マネージドキー を表示して、キーポリシーを表示し、AWS CloudTrail ログでその使用を監査できます。ただし、これらの KMS キーを管理したり許可を変更したりすることはできません。 保管時の暗号化は、テーブルの暗号化に使用される DynamoDB (`aws/dynamodb`) 用の AWS マネージドキー を管理するために AWS KMS と自動的に統合されます。暗号化された DynamoDB テーブルを作成したときにAWS マネージドキー が存在しない場合、AWS KMS は自動的に新しいキーを作成します。このキーは、この先作成するテーブルの暗号化に使用されます。AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウド向けに拡張されたキー管理システムを提供します。 AWS マネージドキー の許可を管理する方法の詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[AWS マネージドキー の使用の承認](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-authz)」を参照してください。 ## カスタマーマネージドキー カスタマーマネージドキーは、お客様が作成、所有、管理する AWS アカウントの KMS キーです。この KMS キーでは、キーポリシー、IAM ポリシー、および許可の確立と管理、有効化と無効化、暗号化対象のローテーション、タグの追加、KMS キーを参照するエイリアスの作成、削除スケジュールの設定などを完全に制御することができます。カスタマーマネージドキーの許可を管理する方法の詳細については、「[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。 カスタマーマネージドキーをテーブルレベルの暗号化キーとして指定すると、DynamoDB テーブル、ローカルおよびグローバルセカンダリインデックス、およびストリームは、同じカスタマーマネージドキーで暗号化されます。オンデマンド Backup は、Backup の作成時に指定されたテーブルレベルの暗号化キーを使用して暗号化されます。テーブルレベルの暗号化キーを更新しても、既存のオンデマンド Backup に関連付けられている暗号化キーは変更されません。 カスタマーマネージドキーの状態を無効に設定するか、削除のスケジュールを設定すると、すべてのユーザーと DynamoDB サービスは、データの暗号化と復号化、およびテーブルに対する読み取り/書き込み操作を実行できなくなります。テーブルに対するアクセスを維持し、データ損失を防止するには、DynamoDB が暗号化キーにアクセスできる必要があります。 カスタマーマネージドキーを無効化したり、削除をスケジュールしたりすると、テーブルステータスは**アクセス不能**になります。テーブルの操作を続行できるようにするには、指定された暗号化キーへの DynamoDB アクセスを 7 日以内に提供する必要があります。暗号化キーにアクセスできないことが検出されると、DynamoDB から警告メール通知が送信されます。 **注記** DynamoDB サービスがカスタマーマネージドキーに 7 日以上アクセスできない場合、テーブルはアーカイブされてアクセスできなくなります。DynamoDB は、テーブルのオンデマンド Backup を作成し、それに対して課金されます。このオンデマンド Backup を使用して、データを新しいテーブルに復元できます。復元を開始するには、最後に使用したカスタマーマネージドキーをテーブルで有効にし、DynamoDB からのアクセスを確立します。 グローバルテーブルレプリカの暗号化に使用したカスタマーマネージドキーにアクセスできない場合、DynamoDB は、このレプリカをレプリケーショングループから除外します。レプリカは削除されず、このリージョンに対するレプリケーションは、カスタマーマネージドキーにアクセス不能と検出されてから 20 時間後に停止します。 詳細については、「[キーの有効化](/kms/latest/developerguide/enabling-keys.html)」と「[キーの削除](/kms/latest/developerguide/deleting-keys.html)」を参照してください。 ## AWS マネージドキー の使用に関する注意事項 AWS KMS アカウントに保存されている KMS キーにアクセスできない場合、Amazon DynamoDB はテーブルデータを読み取れません。DynamoDB は、エンベロープ暗号化とキー階層を使用してデータを暗号化します。AWS KMS 暗号化キーは、このキー階層のルートキーを暗号化するために使用されます。詳細については、「AWS Key Management Service デベロッパーガイド**」の「[エンベロープ暗号化](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)」を参照してください。 DynamoDB は、DynamoDB オペレーションごとに AWS KMS を呼び出すわけではありません。キーは、アクティブなトラフィックを持つ呼び出しごとに 5 分に 1 回更新されます。 SDK が接続を再利用するように設定されていることを確認してください。そうしないと、DynamoDB は、オペレーションごとに新しい AWS KMS キャッシュエントリを再確立しなければならなくなるのでレイテンシーが発生します。さらに、AWS KMSと CloudTrail のコストが上がってしまう可能性もあります。たとえば、Node.js SDK を使用してこれを行うには、`keepAlive` を有効にした状態で新しい HTTPS エージェントを作成することができます。詳細については、「*AWS SDK for JavaScript デベロッパーガイド*」の「[Node.js での keepAlive の設定](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/node-reusing-connections.html)」を参照してください。 # DynamoDB の保管時の暗号化の使用に関する注意事項 Amazon DynamoDB で保管時の暗号化を使用する場合は、以下の点を考慮してください。 ## すべてのテーブルデータの暗号化 保管時のサーバー側の暗号化は、すべての DynamoDB テーブルデータで有効になり、無効にできません。テーブル内の項目のサブセットのみを暗号化することはできません。 保管時の暗号化は、永続的ストレージメディアの静的 (保管時) のデータのみを暗号化します。転送中のデータあるいは使用中のデータでデータの安全性が考慮される場合には、追加の対策を実行する必要がある場合があります。 + 転送中のデータ: DynamoDB のすべてのデータは転送時に暗号化されます。デフォルトでは、DynamoDB との通信において、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) 暗号化を使用してネットワークトラフィックを保護する HTTPS プロトコルが使用されます。 + 使用中のデータ: DynamoDB 送信する前のデータを保護するには、クライアント側の暗号化を使用します。詳細については、「*Amazon DynamoDB Encryption Client デベロッパーガイド*」の「[クライアント側とサーバー側の暗号化](https://docs.aws.amazon.com/dynamodb-encryption-client/latest/devguide/client-server-side.html)」を参照してください。 暗号化されたテーブルでストリーミングを使用できます。DynamoDB Streams は、テーブルレベルの暗号化キーを使用して常に暗号化されます。詳細については、「[DynamoDB Streams の変更データキャプチャ](Streams.md)」を参照してください。 DynamoDB バックアップが暗号化され、バックアップから復元されたテーブルでも暗号化が有効になります。バックアップデータの暗号化に、AWS 所有のキー、AWS マネージドキー、またはカスタマーマネージドキーを使用できます。詳細については、「[DynamoDB のバックアップと復元](Backup-and-Restore.md)」を参照してください。 ローカルセカンダリインデックスおよびグローバルセカンダリインデックスは、ベーステーブルと同じキーを使用して暗号化されます。 ## 暗号化タイプ **注記** カスタマーマネージドキーは、グローバルテーブルバージョン 2017 ではサポートされていません。DynamoDB グローバルテーブルでカスタマーマネージドキーを使用する場合は、テーブルをグローバルテーブルバージョン 2019 にアップグレードしてから有効にする必要があります。 AWS マネジメントコンソール では、AWS マネージドキー またはカスタマーマネージドキーを使用してデータを暗号化すると、暗号化タイプは `KMS` になります。AWS 所有のキー を使用すると、暗号化タイプは `DEFAULT` になります。Amazon DynamoDB API では、AWS マネージドキー またはカスタマーマネージドキーを使用すると暗号化タイプは `KMS` になります。暗号化タイプがない場合、データは AWS 所有のキー を使用して暗号化されます。AWS 所有のキー、AWS マネージドキー、カスタマーマネージドキーはいつでも切り替えることができます。コンソール、AWS Command Line Interface (AWS CLI)、または Amazon DynamoDB API を使用して、暗号化キーを切り替えることができます。 カスタマーマネージドキーを使用する場合、次の制限に注意してください。 + DynamoDB アクセラレーター (DAX) クラスターではカスタマーマネージドキーは使用できません。詳細については、「[保管時の DAX 暗号化](DAXEncryptionAtRest.md)」を参照してください。 + カスタマーマネージドキーを使用して、トランザクションを使用するテーブルを暗号化できます。ただし、トランザクションの伝達の堅牢性を確保するために、トランザクションリクエストのコピーはサービスによって一時的に保存され、AWS 所有のキー を使用して暗号化されます。テーブルとセカンダリインデックスのコミット済みデータは、カスタマーマネージドキーを使用して常に保管時に暗号化されます。 + カスタマーマネージドキーを使用して、Contributor Insights を使用するテーブルを暗号化できます。ただし、Amazon CloudWatch に送信されるデータは、AWS 所有のキー を使用して暗号化されます。 + 新しいカスタマーマネージドキーに移行する場合は、プロセスが完了するまで元のキーを有効にしておいてください。AWS では、新しいキーでデータを暗号化する前に、元のキーを使用してデータを復号化する必要があります。テーブルの SSEDescription ステータスが有効になり、新しいカスタマーマネージドキーの KMSmasterKeyArn が表示されると、プロセスは完了します。この時点で、元のキーを無効にするか、削除のスケジュールを設定できます。 + 新しいカスタマー管理のキーが表示されると、テーブルと新しいオンデマンドバックアップが新しいキーで暗号化されます。 + 既存のオンデマンドバックアップは、バックアップの作成時に使用されたカスタマー管理のキーで暗号化されたままになります。これらのバックアップを復元するには、同じキーが必要です。DescribeBackup API を使用してバックアップの SSEDescription を表示することで、各バックアップが作成された期間のキーを識別できます。 + カスタマーマネージドキーを無効化した場合、または削除をスケジュールした場合、DynamoDB Streams 内のデータは 24 時間保持されます。作成後 24 時間を超えた未取得のアクティビティデータはすべて、トリミングの対象となります。 + カスタマーマネージドキーを無効化した場合、または削除をスケジュールした場合、有効期限 (TTL) は 30 分間続きます。これらの TTL 削除は引き続き DynamoDB Streams に出力され、標準のトリミングまたは保持間隔が適用されます。 詳細については、「[キーの有効化](/kms/latest/developerguide/enabling-keys.html)」と「[キーの削除](/kms/latest/developerguide/deleting-keys.html)」を参照してください。 ## KMS キーとデータキーを使用する DynamoDB の保存時の暗号化機能は、AWS KMS key およびデータキーの階層を使用してテーブルのデータを保護します。DynamoDB は、同じキー階層を使用して、DynamoDB Streams、グローバルテーブル、およびバックアップが耐久性のあるメディアに書き込まれるときに保護します。 DynamoDB にテーブルを実装する前に、暗号化戦略を計画することをお勧めします。機密データまたは機密データを DynamoDB に保存する場合は、クライアント側の暗号化をプランに含めることを検討してください。これにより、データをできるだけ送信元に近い状態で暗号化し、ライフサイクル全体にわたってデータを確実に保護できます。詳細については、「[DynamoDB 暗号化クライアント](https://docs.aws.amazon.com/dynamodb-encryption-client/latest/devguide/what-is-ddb-encrypt.html)」ドキュメントを参照してください。 **AWS KMS key** 保存時の暗号化機能は、AWS KMS key の DynamoDB テーブルを保護します。デフォルトでは、DynamoDB は [AWS 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) (DynamoDB サービスアカウントで作成および管理されるマルチテナントキー) を使用します。ただし、DynamoDB テーブルは、[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)または AWS アカウント の DynamoDB (`aws/dynamodb`) 用で暗号化できます。テーブルごとに異なる KMS キーを選択できます。テーブル用に選択した KMS キーも、ローカルおよびグローバルのセカンダリインデックス、ストリーム、バックアップの暗号化に使用されます。 テーブルを作成または更新するときは、テーブル用の KMS キーを選択します。テーブル用 KMS キーは、DynamoDB コンソールで、または [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) オペレーションを使用していつでも変更できます。キーの切り替えプロセスはシームレスであり、ダウンタイムやサービスの低下を必要としません。 DynamoDB は、[対称 KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)のみをサポートします。[非対称 KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html#asymmetric-cmks)を使用して DynamoDB テーブルを暗号化することはできません。 カスタマーマネージドキーを使用して次の機能を取得します。 + KMS キーを作成および管理します。これには、[キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)および [IAM ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html)の設定、KMS キーへのアクセスを制御する[グラント](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)が含まれます。KMS キーの[有効化または無効化](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html)、[自動キーローテーション](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)の有効化または無効化、使用しなくなった [KMS キーの削除](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)を実行できます。 + [インポートされたキーマテリアル](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html)を持つカスタマーマネージドキー、またはユーザーが所有して管理する[カスタムキーストア](https://docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html)で、カスタマーマネージドキーを使用できます。 + DynamoDB テーブルの暗号化と復号を監査するには、 [AWS CloudTrail ログ](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-cmk-trail)で AWS KMS への DynamoDB API コールを調べます。 次のいずれかの機能が必要なときは、AWS マネージドキー を使用します。 + [KMS キーを表示し](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys.html)、[そのキーポリシーを表示](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-viewing.html)できます。(キーポリシーの変更はできません)。 + DynamoDB テーブルの暗号化と復号を監査するには、 [AWS CloudTrail ログ](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-cmk-trail)で AWS KMS への DynamoDB API コールを調べます。 ただし、AWS 所有のキー は無料で、その使用は [AWS KMS リソースクォータまたはリクエストクォータ](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)に対してカウントされません。カスタマーマネージドキーおよび AWS マネージドキー には、API コールごとに[料金が発生](https://aws.amazon.com/kms/pricing/)し、これらの KMS キーには AWS KMS クォータが適用されます。 **テーブルキー** DynamoDB は、テーブルの KMS キーを使用して、*テーブルキー*と呼ばれるテーブルの一意の[データキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys)を[生成](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)して暗号化します。テーブルキーは、暗号化されたテーブルの存続期間中は保持されます。 テーブルキーは、キー暗号化キーとして使用されます。DynamoDB は、このテーブルキーを使用して、テーブルデータの暗号化に使用されるデータ暗号化キーを保護します。DynamoDB は、テーブル内の基礎となる各構造に対して一意のデータ暗号化キーを生成しますが、複数のテーブル項目が同じデータ暗号化キーで保護される場合があります。 ![\[保管時の暗号化で DynamoDB テーブルを暗号化する\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/service-ddb-encrypt.png) 暗号化されたテーブルに最初にアクセスすると、DynamoDB は、KMS キーを使用してテーブルキーを復号するリクエストを AWS KMS に送信します。その後、プレーンテキストテーブルキーを使用してデータ暗号化キーを復号化し、プレーンテキストデータ暗号化キーを使用してテーブルデータを復号化します。 DynamoDB は AWS KMS の外部でテーブルキーとデータ暗号化キーを保存して使用します。これによって、[Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) (AES) 暗号化および 256 ビット暗号化キーのすべてのキーが保護されます。続いて、暗号化されたキーを暗号化されたデータと一緒に保存します。これらのキーおよびデータは、必要なときにテーブルデータの暗号化に使用できます。 テーブルの KMS キーを変更すると、DynamoDB は新しいテーブルキーを生成します。次に、新しいテーブルキーを使用してデータ暗号化キーの再暗号化が行われます。 **テーブルキーのキャッシュ** DynamoDB オペレーションごとに AWS KMS を呼び出さないように、DynamoDB は各呼び出しのプレーンテキストのテーブルキーをメモリにキャッシュします。DynamoDB では、キャッシュしたテーブルキーが 5 分間非アクティブ状態であった後にリクエストを取得すると、AWS KMS に新しいリクエストを送信してテーブルキーを復号します。この呼び出しは、テーブルキーの復号を求める前回のリクエスト以降に AWS KMS または AWS Identity and Access Management (IAM) で KMS キーのアクセスポリシーに加えられた変更をすべてキャプチャします。 ## KMS キーの使用を認可する DynamoDB テーブルを保護するために、アカウントで[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)または [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用する場合は、その KMS キーのポリシーが DynamoDB に、ユーザーに代わってキーを使用する許可を付与する必要があります。DynamoDB の AWS マネージドキー の認可コンテキストには、そのキーポリシーとそれを使用するアクセス許可を委任するグラントが含まれます。 AWS マネージドキー はアカウントにあり、そのポリシーとグラントを表示できるため、カスタマーマネージドキーのポリシーとグラントを完全に制御することができます。ただし、AWS によって管理されているため、ポリシーを変更することはできません。 DynamoDB では、デフォルトの [AWS 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) を使用して AWS アカウント の DynamoDB テーブルを保護するための追加の認可は不要です。 **Topics** + [AWS マネージドキー のキーポリシー](#dynamodb-policies) + [カスタマーマネージドキーのキーポリシー](#dynamodb-customer-cmk-policy) + [グラントを使用した DynamoDB の承認](#dynamodb-grants) ### AWS マネージドキー のキーポリシー DynamoDB は、[DynamoDB リソース](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html)にアクセスしているユーザーの代わりに、暗号化オペレーションで DynamoDB (`aws/dynamodb`) の [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用します。AWS マネージドキー のキーポリシーはアカウントのすべてのユーザーに、指定されたオペレーションで AWS マネージドキー を使用する許可を付与します。ただし、アクセス許可が付与されるのは、DynamoDB がユーザーの代わりにリクエストを行う場合のみです。キーポリシーの [ViaService 条件](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)では、リクエストが DynamoDB サービスで発生しない限り、ユーザーに AWS マネージドキー の使用を許可しません。 このキーポリシーは、すべての AWS マネージドキー のポリシーと同様に、AWS によって確立されます。このポリシーを変更することはできませんが、いつでも表示できます。詳細については、「[Viewing a key policy](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-viewing.html)」を参照してください。 このキーポリシーのポリシーステートメントには次の効果があります + リクエストがユーザーの代わりに DynamoDB から送信された場合、アカウントのユーザーが DynamoDB の AWS マネージドキー を暗号化オペレーションで使用することを許可します。また、このポリシーはユーザーに KMS キーの[グラントの作成](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-grants)も許可します。 + 認可された IAM がアカウントで DynamoDB の AWS マネージドキー のプロパティを表示し、DynamoDB の KMS キー使用を許可する[グラントを取り消す](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html)ことができるようにします。DynamoDB は、継続的なメンテナンス操作に[グラント](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-grants)を使用します。 + DynamoDB が読み取り専用オペレーションを実行して、アカウントで DynamoDB の AWS マネージドキー を検索できるようにします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id" : "auto-dynamodb-1", "Statement" : [ { "Sid" : "Allow access through Amazon DynamoDB for all principals in the account that are authorized to use Amazon DynamoDB", "Effect" : "Allow", "Principal" : { "AWS" : "*" }, "Action" : [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:CreateGrant", "kms:DescribeKey" ], "Resource" : "*", "Condition" : { "StringEquals" : { "kms:CallerAccount" : "111122223333", "kms:ViaService" : "dynamodb.us-west-2.amazonaws.com" } } }, { "Sid" : "Allow direct access to key metadata to the account", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::111122223333:root" }, "Action" : [ "kms:Describe*", "kms:Get*", "kms:List*", "kms:RevokeGrant" ], "Resource" : "*" }, { "Sid" : "Allow DynamoDB Service with service principal name dynamodb.amazonaws.com to describe the key directly", "Effect" : "Allow", "Principal" : { "Service" : "dynamodb.amazonaws.com" }, "Action" : [ "kms:Describe*", "kms:Get*", "kms:List*" ], "Resource" : "*" } ] } ``` ------ ### カスタマーマネージドキーのキーポリシー [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)を選択して DynamoDB テーブルを保護する際、DynamoDB は、選択を行うプリンシパルの代わりに KMS キーを使用するアクセス許可を取得します。そのプリンシパル、ユーザー、ロールは、DynamoDB に必要な KMS キーに対するアクセス許可を持っている必要があります。これらの許可は、[キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)、[IAM ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html)、または[グラント](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)で指定できます。 DynamoDB には、少なくとも、カスタマーマネージドキーに対する次のアクセス許可が必要です。 + [kms:Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) + [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) + [kms:ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)\$1 (for kms:ReEncryptFrom および kms:ReEncryptTo 向け) + kms:GenerateDataKey\$1 (for [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) および [kms:GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html) 向け) + [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) + [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) 例えば、次のキーポリシーの例では、必要なアクセス許可のみを提供します。このポリシーには、以下の影響があります。 + DynamoDB が、DynamoDB の使用許可を持つアカウントのプリンシパルの代わりに動作している場合にのみ、DynamoDB が暗号化オペレーションで KMS キーを使用し、グラントを作成することを許可します。ポリシーステートメントで指定されたプリンシパルに DynamoDB を使用する権限がない場合、呼び出しは DynamoDB サービスからのものであっても失敗します。 + [KMS: viaService 条件キーでは、ポリシ](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) ーステートメントにリストされているプリンシパルの代わりに DynamoDB からリクエストが送信された場合にのみアクセス許可が許可されます。これらのプリンシパルは、これらのオペレーションを直接呼び出すことはできません。`kms:ViaService` の値である `dynamodb.*.amazonaws.com` は、リージョンの位置にアスタリスク (\$1) が付いていることに注意してください。DynamoDB では、クロスリージョン呼び出しを実行して [DynamoDB グローバルテーブル](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)をサポートできるように、特定の AWS リージョン から独立したアクセス許可が必要です。 + KMS キー管理者 (`db-team` ロールを引き受けることができるユーザー) に、KMS キーへの読み取り専用アクセス許可、およびグラント (テーブルを保護するために [DynamoDB が必要とするグラント](#dynamodb-grants)を含む) を取り消す許可を付与します。 サンプルキーポリシーを使用する前に、サンプルプリンシパルを AWS アカウント の実際のプリンシパルに置き換えます。 ------ #### [ JSON ] **** ``` { "Id": "key-policy-dynamodb", "Version":"2012-10-17", "Statement": [ { "Sid" : "Allow access through Amazon DynamoDB for all principals in the account that are authorized to use Amazon DynamoDB", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:user/db-lead"}, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey", "kms:CreateGrant" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService" : "dynamodb.*.amazonaws.com" } } }, { "Sid": "Allow administrators to view the KMS key and revoke grants", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/db-team" }, "Action": [ "kms:Describe*", "kms:Get*", "kms:List*", "kms:RevokeGrant" ], "Resource": "*" } ] } ``` ------ ### グラントを使用した DynamoDB の承認 キーポリシーに加えて、DynamoDB は DynamoDB (`aws/dynamodb`) のためにカスタマーマネージドキーまたは AWS マネージドキー の許可を設定するためのグラントを使用します。アカウントの KMS キーのグラントを表示するには、[ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) 操作を使用します。DynamoDB では、[AWS 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) を使用してテーブルを保護するために、グラントや追加のアクセス許可は必要ありません。 DynamoDB は、バックグラウンドシステムメンテナンスと継続的なデータ保護タスクを実行するときに、許可を付与します。また、[テーブルキー](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html#dynamodb-encrypt)の生成にグラントを使用します。 各グラントは、テーブルに固有です。アカウントに同じ KMS キーで暗号化された複数のテーブルがある場合、テーブルごとに各タイプのグラントがあります。グラントは、テーブル名と AWS アカウント ID を含む [DynamoDB 暗号化コンテキスト](#dynamodb-encryption-context)によって制約を受けます。また、グラントには、それが不要になった場合に[グラントを使用停止にする](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html)許可が含まれます。 グラントを作成するには、DynamoDB に、暗号化されたテーブルを作成したユーザーに代わって `CreateGrant` を呼び出すための許可が必要です。AWS マネージドキー では、DynamoDB が認可されたユーザーの代わりにリクエストを行う場合にのみ、アカウントのユーザーに KMS キーで [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) の呼び出しを許可する[キーポリシー](#dynamodb-policies)からの `kms:CreateGrant` 許可を DynamoDB が取得します。 キーポリシーは、アカウントが KMS キーの[グラントを取り消す](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html)ことも許可できます。ただし、アクティブな暗号化されたテーブルのグラントを取り消すと、DynamoDB はテーブルを保護および維持できなくなります。 ## DynamoDB 暗号化コンテキスト [暗号化コンテキスト](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context)は、一連のキー値のペアおよび任意非シークレットデータを含みます。データを暗号化するリクエストに暗号化コンテキストを組み込むと、AWS KMS は暗号化コンテキストを暗号化されたデータに暗号化してバインドします。データを復号するには、同じ暗号化コンテキストに渡す必要があります。 DynamoDB は、すべての AWS KMS 暗号化オペレーションで同じ暗号化コンテキストを使用します。[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)または [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用して DynamoDB テーブルを保護する場合、暗号化コンテキストを使用して監査レコードやログにおける KMS キーの使用を特定することができます。これは、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) や [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) などのログにもプレーンテキストで表示されます。 また、暗号化コンテクストはポリシーとグラントの認可用の条件としても使用できます。DynamoDB は暗号化コンテキストを使用して、アカウントとリージョンのカスタマーマネージドキーまたは AWS マネージドキー へのアクセスを許可する[グラント](#dynamodb-grants)を制限します。 DynamoDB は AWS KMS へのリクエストで、2 つのキーバリューペアを持つ暗号化コンテキストを使用します。 ``` "encryptionContextSubset": { "aws:dynamodb:tableName": "Books" "aws:dynamodb:subscriberId": "111122223333" } ``` + **テーブル** — 最初のキーと値のペアは、DynamoDB が暗号化しているテーブルを識別します。キーは、`aws:dynamodb:tableName` です。この値は、テーブルの名前です。 ``` "aws:dynamodb:tableName": "" ``` 以下はその例です。 ``` "aws:dynamodb:tableName": "Books" ``` + **アカウント** － 2 番目のキーバリューペアは、AWS アカウント を識別します。キーは、`aws:dynamodb:subscriberId` です。値は、アカウント ID です。 ``` "aws:dynamodb:subscriberId": "" ``` 以下はその例です。 ``` "aws:dynamodb:subscriberId": "111122223333" ``` ## DynamoDB の AWS KMS との対話をモニタリングする [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)または [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用して DynamoDB テーブルを保護する場合は、AWS CloudTrail ログを使用して、DynamoDB がユーザーに代わって AWS KMS に送信するリクエストを追跡することができます。 このセクションでは、`GenerateDataKey`、`Decrypt`、および `CreateGrant` リクエストを説明します。さらに、DynamoDB は [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) オペレーションを使用して、選択した KMS キーがアカウントとリージョンに存在するかどうかを判断します。また、 [RetireGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) 操作を使用して、テーブルを削除するときにグラントを削除します。 **GenerateDataKey** テーブルで保存時の暗号化を有効にすると、DynamoDB は一意のテーブルキーを作成します。また、*[GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)* リクエストを、テーブルの KMS キーを指定する AWS KMS に送信します。 `GenerateDataKey` 演算を記録するイベントは、次のようなサンプルイベントになります。ユーザーは DynamoDB サービスアカウントです。パラメータには、KMS キーの Amazon リソースネーム (ARN)、256 ビットキーを必要とするキー指定子、テーブルと AWS アカウント を識別する[暗号化コンテキスト](#dynamodb-encryption-context)が含まれます。 ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSService", "invokedBy": "dynamodb.amazonaws.com" }, "eventTime": "2018-02-14T00:15:17Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKey", "awsRegion": "us-west-2", "sourceIPAddress": "dynamodb.amazonaws.com", "userAgent": "dynamodb.amazonaws.com", "requestParameters": { "encryptionContext": { "aws:dynamodb:tableName": "Services", "aws:dynamodb:subscriberId": "111122223333" }, "keySpec": "AES_256", "keyId": "1234abcd-12ab-34cd-56ef-1234567890ab" }, "responseElements": null, "requestID": "229386c1-111c-11e8-9e21-c11ed5a52190", "eventID": "e3c436e9-ebca-494e-9457-8123a1f5e979", "readOnly": true, "resources": [ { "ARN": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "accountId": "111122223333", "type": "AWS::KMS::Key" } ], "eventType": "AwsApiCall", "recipientAccountId": "111122223333", "sharedEventID": "bf915fa6-6ceb-4659-8912-e36b69846aad" } ``` **Decrypt** 暗号化された DynamoDB テーブルにアクセスする場合、DynamoDB はテーブルキーを復号化して、階層内でその下にあるキーを復号化できるようにする必要があります。次に、テーブル内のデータを復号化します。テーブルキーを復号化するには、次が実行されます。DynamoDB は、テーブルの KMS キーを指定する[復号](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)リクエストを AWS KMS に送信します。 `Decrypt` 演算を記録するイベントは、次のようなサンプルイベントになります。ユーザーは、テーブルにアクセスしている AWS アカウント のプリンシパルです。パラメータには、暗号化されたテーブルキー (暗号化テキストの blob として)、およびテーブルと AWS アカウント を識別する[暗号化コンテキスト](#dynamodb-encryption-context)が含まれます。AWS KMS は、暗号化テキストから KMS キーの ID を取得します。 ``` { "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROAIGDTESTANDEXAMPLE:user01", "arn": "arn:aws:sts::111122223333:assumed-role/Admin/user01", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2018-02-14T16:42:15Z" }, "sessionIssuer": { "type": "Role", "principalId": "AROAIGDT3HGFQZX4RY6RU", "arn": "arn:aws:iam::111122223333:role/Admin", "accountId": "111122223333", "userName": "Admin" } }, "invokedBy": "dynamodb.amazonaws.com" }, "eventTime": "2018-02-14T16:42:39Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "us-west-2", "sourceIPAddress": "dynamodb.amazonaws.com", "userAgent": "dynamodb.amazonaws.com", "requestParameters": { "encryptionContext": { "aws:dynamodb:tableName": "Books", "aws:dynamodb:subscriberId": "111122223333" } }, "responseElements": null, "requestID": "11cab293-11a6-11e8-8386-13160d3e5db5", "eventID": "b7d16574-e887-4b5b-a064-bf92f8ec9ad3", "readOnly": true, "resources": [ { "ARN": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "accountId": "111122223333", "type": "AWS::KMS::Key" } ], "eventType": "AwsApiCall", "recipientAccountId": "111122223333" } ``` **CreateGrant** [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)または [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用して DynamoDB テーブルを保護する場合、DynamoDB は[グラント](#dynamodb-grants)を使用して、サービスが継続的なデータ保護、メンテナンス、耐久性のタスクを実行できるようにします。これらのグラントは、[AWS 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) では不要です。 DynamoDB が作成するグラントは、テーブルに固有です。[CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) リクエストのプリンシパルは、テーブルを作成したユーザーです。 `CreateGrant` 演算を記録するイベントは、次のようなサンプルイベントになります。パラメータには、テーブルの KMS キーの Amazon リソースネーム (ARN)、被付与者プリンシパルと使用停止プリンシパル (DynamoDB サービス)、グラントの対象となるオペレーションが含まれます。また、指定された[暗号化コンテキスト](#dynamodb-encryption-context)を使用するすべての暗号化オペレーションを必要とする制約も含まれています。 ``` { "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROAIGDTESTANDEXAMPLE:user01", "arn": "arn:aws:sts::111122223333:assumed-role/Admin/user01", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2018-02-14T00:12:02Z" }, "sessionIssuer": { "type": "Role", "principalId": "AROAIGDTESTANDEXAMPLE", "arn": "arn:aws:iam::111122223333:role/Admin", "accountId": "111122223333", "userName": "Admin" } }, "invokedBy": "dynamodb.amazonaws.com" }, "eventTime": "2018-02-14T00:15:15Z", "eventSource": "kms.amazonaws.com", "eventName": "CreateGrant", "awsRegion": "us-west-2", "sourceIPAddress": "dynamodb.amazonaws.com", "userAgent": "dynamodb.amazonaws.com", "requestParameters": { "keyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "retiringPrincipal": "dynamodb.us-west-2.amazonaws.com", "constraints": { "encryptionContextSubset": { "aws:dynamodb:tableName": "Books", "aws:dynamodb:subscriberId": "111122223333" } }, "granteePrincipal": "dynamodb.us-west-2.amazonaws.com", "operations": [ "DescribeKey", "GenerateDataKey", "Decrypt", "Encrypt", "ReEncryptFrom", "ReEncryptTo", "RetireGrant" ] }, "responseElements": { "grantId": "5c5cd4a3d68e65e77795f5ccc2516dff057308172b0cd107c85b5215c6e48bde" }, "requestID": "2192b82a-111c-11e8-a528-f398979205d8", "eventID": "a03d65c3-9fee-4111-9816-8bf96b73df01", "readOnly": false, "resources": [ { "ARN": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "accountId": "111122223333", "type": "AWS::KMS::Key" } ], "eventType": "AwsApiCall", "recipientAccountId": "111122223333" } ``` # DynamoDB での暗号化テーブルの管理 AWS マネジメントコンソール または AWS Command Line Interface (AWS CLI) を使用すると、新しいテーブルで暗号化キーを指定し、Amazon DynamoDB の既存のテーブルで暗号化キーを更新できます。 **Topics** + [新しいテーブルの暗号化キーを指定する](#encryption.tutorial-creating) + [暗号化キーの更新](#encryption.tutorial-update) ## 新しいテーブルの暗号化キーを指定する Amazon DynamoDB コンソールまたは AWS CLI を使用して新しいテーブルで暗号化キーを指定するには、以下の手順に従います。 ### 暗号化されたテーブルの作成 (コンソール) 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. コンソールの左側のナビゲーションペインで、**[テーブル]** を選択します。 1. **[Create Table]** (テーブルの作成) を選択します。**[Table name]** (テーブル名) に「**Music**」と入力します。プライマリキーに「**Artist**」と入力し、ソートキーに「**SongTitle**」をそれぞれ文字列として入力します。 1. **[Settings]** (設定) では、**[Customize settings]** (設定のカスタマイズ) が選択されていることを確認してください。 **注記** **[Use default settings]** (デフォルト設定の使用) を選択した場合、テーブルは AWS 所有のキー を使用して保管時に暗号化され、追加コストはかかりません。 1. **[Encryption at rest]** (保管時の暗号化) で、暗号化タイプ – AWS 所有のキー、AWS マネージドキー、またはカスタマーマネージドキーを選択します。 + **[Owned by Amazon DynamoDB]** (Amazon DynamoDB が所有)。AWS が所有するキーで、特に DynamoDB が所有および管理します。このキーは追加料金なしで使用されます。 + **AWS マネージドキー**。キーエイリアス: `aws/dynamodb`。キーはアカウントに保存され、AWS Key Management Service (AWS KMS) によって管理されます (AWS KMS の料金が適用されます)。 + **[Stored in your account, and owned and managed by you.] (アカウントに保存され、お客様が所有および管理。**) カスタマーマネージドキー。キーはアカウントに保存され、AWS Key Management Service (AWS KMS) によって管理されます (AWS KMS の料金が適用されます)。 **注記** 独自のキーを所有および管理することを選択した場合は、KMS キーポリシーが適切に設定されていることを確認してください。例を含む詳細については、「[カスタマーマネージドキーのキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。 1. **[Create table]** (テーブルの作成) を選択して暗号化テーブルを作成します。暗号化タイプを確認するには、**[Overview]** (概要) タブのテーブルの詳細を選択し、**[Additional details]** (その他の詳細) セクションを表示します。 ### 暗号化されたテーブルの作成 (AWS CLI) AWS CLI により、Amazon DynamoDB のデフォルトの AWS 所有のキー、AWS マネージドキー、またはカスタマーマネージドキーを使用してテーブルを作成します。 **デフォルトの AWS 所有のキー で暗号化テーブルを作成するには** + 暗号化された `Music` テーブルを次のとおりに作成します。 ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 ``` **注記** このテーブルは、DynamoDB サービスアカウントでデフォルトの AWS 所有のキー を使用して暗号化されます。 **AWS マネージドキー で DynamoDB 用の暗号化テーブルを作成するには** + 暗号化された `Music` テーブルを次のとおりに作成します。 ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 \ --sse-specification Enabled=true,SSEType=KMS ``` テーブルの説明の `SSEDescription` ステータスは、`ENABLED` に設定され、`SSEType` は `KMS` になります。 ``` "SSEDescription": { "SSEType": "KMS", "Status": "ENABLED", "KMSMasterKeyArn": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234", } ``` **カスタマーマネージドキーで DynamoDB 用の暗号化テーブルを作成するには** + 暗号化された `Music` テーブルを次のとおりに作成します。 ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 \ --sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=abcd1234-abcd-1234-a123-ab1234a1b234 ``` **注記** `KMSMasterKeyId` の場合、キー ID、キー ARN、またはキーエイリアスを使用できます。キーエイリアス (`alias/my-key` など) を使用する場合、DynamoDB はエイリアスを解決し、基盤となる AWS KMS キーをテーブルに関連付けます。テーブルの説明では、`KMSMasterKeyArn` はエイリアスではなく、解決されたキーのキー ARN を常に表示します。キー識別子の詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[キー識別子 (KeyId)](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-id)」を参照してください。 テーブルの説明の `SSEDescription` ステータスは、`ENABLED` に設定され、`SSEType` は `KMS` になります。 ``` "SSEDescription": { "SSEType": "KMS", "Status": "ENABLED", "KMSMasterKeyArn": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234", } ``` ## 暗号化キーの更新 DynamoDB コンソールまたは AWS CLI を使用して、AWS 所有のキー、AWS マネージドキー、カスタマーマネージドキーの間でいつでも既存のテーブルの暗号化キーを更新することができます。 ### 暗号化キーの更新 (コンソール) 1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. コンソールの左側のナビゲーションペインで、**[テーブル]** を選択します。 1. 更新するテーブルを選択します。 1. **[Actions]** (アクション) ドロップダウンを選択し、**[Update settings]** (設定の更新) オプションを選択します。 1. **[Additional settings]** (追加設定) タブに移動します。 1. **[Encryption]** (暗号化) の下の、**[Manage encryption]** (暗号化の管理) を選択します。 1. 暗号化タイプを選択します。 + **[Owned by Amazon DynamoDB.] (Amazon DynamoDB によって所有される。**) AWS KMS キーは DynamoDB によって所有、管理されます。このキーは追加料金なしで使用されます。 + **AWS マネージドキー**のキーエイリアス: `aws/dynamodb`。キーはアカウントに保存され、AWS Key Management Service (AWS KMS) によって管理されます (AWS KMS の料金が適用されます)。 + **[Stored in your account, and owned and managed by you.] (アカウントに保存され、ユーザーが所有、管理される。**) キーはアカウントに保存され、AWS Key Management Service (AWS KMS) によって管理されます (AWS KMS の料金が適用されます)。 **注記** 独自のキーを所有および管理することを選択した場合は、KMS キーポリシーが適切に設定されていることを確認してください。詳細については、「[カスタマーマネージドキーのキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。 続いて、**[Save]** (保存) を選択して暗号化されたテーブルを更新します。暗号化タイプを確認するには、[**概要**] タブでテーブルの詳細を参照します。 ### 暗号化キーの更新 (AWS CLI) 次の例は、AWS CLI を使用して暗号化テーブルを更新する方法を示しています。 **デフォルトの AWS 所有のキー で暗号化テーブルを更新するには** + 暗号化された `Music` テーブルを次の例のとおりに更新します。 ``` aws dynamodb update-table \ --table-name Music \ --sse-specification Enabled=false ``` **注記** このテーブルは、DynamoDB サービスアカウントでデフォルトの AWS 所有のキー を使用して暗号化されます。 **DynamoDB 用の AWS マネージドキー で暗号化テーブルを更新するには** + 暗号化された `Music` テーブルを次の例のとおりに更新します。 ``` aws dynamodb update-table \ --table-name Music \ --sse-specification Enabled=true ``` テーブルの説明の `SSEDescription` ステータスは、`ENABLED` に設定され、`SSEType` は `KMS` になります。 ``` "SSEDescription": { "SSEType": "KMS", "Status": "ENABLED", "KMSMasterKeyArn": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234", } ``` **DynamoDB のカスタマーマネージドキーで暗号化テーブルを更新するには** + 暗号化された `Music` テーブルを次の例のとおりに更新します。 ``` aws dynamodb update-table \ --table-name Music \ --sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=abcd1234-abcd-1234-a123-ab1234a1b234 ``` **注記** `KMSMasterKeyId` の場合、キー ID、キー ARN、またはキーエイリアスを使用できます。キーエイリアス (`alias/my-key` など) を使用する場合、DynamoDB はエイリアスを解決し、基盤となる AWS KMS キーをテーブルに関連付けます。テーブルの説明では、`KMSMasterKeyArn` はエイリアスではなく、解決されたキーのキー ARN を常に表示します。 テーブルの説明の `SSEDescription` ステータスは、`ENABLED` に設定され、`SSEType` は `KMS` になります。 ``` "SSEDescription": { "SSEType": "KMS", "Status": "ENABLED", "KMSMasterKeyArn": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234", } ``` # VPC エンドポイントと IAM ポリシーを使用した DynamoDB 接続の保護 接続は、Amazon DynamoDB とオンプレミスのアプリケーション間、および同じの AWS リージョン内の DynamoDB と他の AWS リソース間で保護されます。 ## エンドポイントに必要なポリシー Amazon DynamoDB には、リージョンのエンドポイント情報を列挙できる [DescribeEndpoints](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeEndpoints.html) API が用意されています。パブリック DynamoDB エンドポイントへのリクエストの場合、API は、IAM または VPC エンドポイントポリシーに明示的または暗黙的な拒否があっても、設定された DynamoDB IAM ポリシーに関係なく応答します。これは、DynamoDB が `DescribeEndpoints` API の承認を意図的にスキップするためです。 VPC エンドポイントからのリクエストの場合、IAM エンドポイントポリシーと仮想プライベートクラウド (VPC) エンドポイントポリシーの両方が、IAM の `dynamodb:DescribeEndpoints` アクションを使用して、リクエスト元の ID およびアクセス管理 (IAM) プリンシパルの `DescribeEndpoints` API コールを承認する必要があります。それ以外の場合、`DescribeEndpoints` API へのアクセスは拒否されます。 以下は、エンドポイントポリシーの例です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "dynamodb:DescribeEndpoints", "Resource": "*" } ] } ``` ------ ## サービスとオンプレミスのクライアントおよびアプリケーションとの間のトラフィック プライベートネットワークと AWS との間には 2 つの接続オプションがあります: + AWS Site-to-Site VPN 接続。詳細については、『*AWS Site-to-Site VPN ユーザーガイド*』の「[What is AWS Site-to-Site VPN? ( とは？)](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」 を参照してください。 + Direct Connect 接続。詳細については、『*Direct Connect ユーザーガイド*』の「[What is Direct Connect? ( とは？)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」 を参照してください。 ネットワークを介した DynamoDB へのアクセスは、AWS が発行する API を利用して行われます。クライアントは Transport Layer Security (TLS) 1.2 をサポートしている必要があります。TLS 1.3 をお勧めします。クライアントは、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) などの Perfect Forward Secrecy (PFS) を備えた暗号スイートもサポートする必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。また、リクエストには、IAM プリンシパルに関連付けられたアクセスキー ID およびシークレットアクセスキーによる署名が必要です。または、リクエストへの署名のために一時的にセキュリティ認証情報を生成する [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) を使用することもできます。 ## 同じリージョン内の AWS リソース間のトラフィック Amazon Virtual Private Cloud (Amazon VPC) endpoint for DynamoDB は、DynamoDB への接続のみを許可する VPC 内の論理エンティティです。Amazon VPC はリクエストを DynamoDB にルーティングし、レスポンスを VPC にルーティングします。詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html)」を参照してください。VPC エンドポイントからのアクセスのコントロールに使用できるポリシーの例については、「[IAM ポリシーを使用して DynamoDB へのアクセスをコントロールします](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-ddb.html)」を参照してください。 **注記** Amazon VPC エンドポイントには、AWS Site-to-Site VPN または Direct Connect を使用してアクセスすることはできません。 # AWS Identity and Access Management (IAM) と DynamoDB AWS Identity and Access Management は、管理者が AWS リソースへのアクセスを安全にコントロールするために役立つ AWS のサービスです。管理者は、誰を認証 (サインイン) し、誰に Amazon DynamoDB および DynamoDB Accelerator リソースの使用を承認する (アクセス許可を付与する) かを制御します。IAM を使用して、Amazon DynamoDB と DynamoDB Accelerator の両方のアクセス許可を管理し、セキュリティポリシーを実装できます。IAM は、AWS のサービスで追加料金は発生しません。 **Topics** + [Amazon DynamoDB の Identity and Access Management](security-iam.md) + [詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) # Amazon DynamoDB の Identity and Access Management AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は、誰が*認証* (サインイン) され、DynamoDB リソースを使用する*認可* を受ける (アクセス許可がある) ことができるかを管理します。IAM は、追加費用なしで使用できる AWS のサービス です。 **Topics** + [対象者](#security_iam_audience) + [アイデンティティによる認証](#security_iam_authentication) + [ポリシーを使用したアクセス権の管理](#security_iam_access-manage) + [Amazon DynamoDB で IAM が機能する仕組み](security_iam_service-with-iam.md) + [Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) + [Amazon DynamoDB アイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md) + [DynamoDB リザーブドキャパシティの購入を防止する IAM ポリシー](iam-policy-prevent-purchase-reserved-capacity.md) ## 対象者 AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。 + **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon DynamoDB アイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。 + **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[Amazon DynamoDB で IAM が機能する仕組み](security_iam_service-with-iam.md)」を参照) + **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照) ## アイデンティティによる認証 認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。 AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。 プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。 ### AWS アカウント のルートユーザー AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。 ### フェデレーテッドアイデンティティ ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。 *フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービス にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。 アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。 ### IAM ユーザーとグループ *[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。 ### IAM ロール *[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。 IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。 ## ポリシーを使用したアクセス権の管理 AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは、アイデンティティやリソースとの関連付けに伴うアクセス許可を定義します。AWS は、プリンシパルがリクエストを行うときに、これらのポリシーを評価します。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。 管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。 デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。 ### アイデンティティベースのポリシー アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。 アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。 ### リソースベースのポリシー リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。 リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。 ### その他のポリシータイプ AWS は、より一般的なポリシータイプで付与された最大数のアクセス許可を設定できる、追加のポリシータイプをサポートしています。 + **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。 + **サービスコントロールポリシー (SCP)** - AWS Organizations 内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。 + **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。 + **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。 ### 複数のポリシータイプ 1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド* の [ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) を参照してください。 # Amazon DynamoDB で IAM が機能する仕組み IAM を使用して DynamoDB へのアクセスを管理する前に、DynamoDB で利用できる IAM の機能について学びます。 | IAM 機能 | DynamoDB のサポート | | --- | --- | | [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり | | [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | はい | | [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり | | [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | あり | | [ポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys) | あり | | [ACL](#security_iam_service-with-iam-acls) | なし | | [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | あり | | [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり | | [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions) | あり | | [サービスロール](#security_iam_service-with-iam-roles-service) | あり | | [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい | 大部分の IAM 機能が DynamoDB および AWS のその他のサービスでどのように連携するかに関するおおまかな説明については、「*IAM ユーザーガイド*」の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ## DynamoDB のアイデンティティベースのポリシー **アイデンティティベースのポリシーのサポート:** あり アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。 IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。 ### DynamoDB のアイデンティティベースのポリシーの例 DynamoDB アイデンティティベースのポリシーの例を確認するには、「[Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## DynamoDB 内のリソースベースのポリシー **リソースベースのポリシーのサポート:** あり リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。 クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。 ## DynamoDB のポリシーアクション **ポリシーアクションのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。 JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。 DynamoDB アクションのリストを確認するには、「*サービス認可リファレンス*」の「[Amazon DynamoDB で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions)」を参照してください。 DynamoDB のポリシーアクションは、アクションの前に以下のプレフィックスを使用します。 ``` aws ``` 単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。 ``` "Action": [ "aws:action1", "aws:action2" ] ``` DynamoDB アイデンティティベースのポリシーの例を確認するには、「[Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## DynamoDB のポリシーリソース **ポリシーリソースのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 `Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。 ``` "Resource": "*" ``` DynamoDB リソースのタイプとその ARN のリストを確認するには、「サービス認可リファレンス」の「[Amazon DynamoDB で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-resources-for-iam-policies)」を参照してください。**各リソースの ARN を指定できるアクションについては、「[Amazon DynamoDB で定義されているアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions)」を参照してください。 DynamoDB アイデンティティベースのポリシーの例を確認するには、「[Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## DynamoDB のポリシー条件キー **サービス固有のポリシー条件キーのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。 `Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。 DynamoDB の条件キーの一覧については、「*サービス認可リファレンス*」の「[Amazon DynamoDB の条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-policy-keys)」を参照してください。どのアクションおよびリソースで条件キーを使用できるかについては、「[Amazon DynamoDB で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions)」を参照してください。 DynamoDB アイデンティティベースのポリシーの例を確認するには、「[Amazon DynamoDB のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。 ## DynamoDB のアクセスコントロールリスト (ACL) **ACL のサポート:** なし アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。 ## DynamoDB での属性ベースのアクセス制御 (ABAC) **ABAC (ポリシー内のタグ) のサポート:** あり 属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグを付けることで、プリンシパルのタグがリソースタグと一致するときに操作を許可する ABAC ポリシーを設計できます。 タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。 サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。 ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。 ## DynamoDB での一時的な認証情報の使用 **一時的な認証情報のサポート:** あり 一時的な認証情報は、AWSリソースへの短期的なアクセスを提供し、フェデレーションの使用時またはロールの切り替え時に自動的に作成されます。AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ## DynamoDB のクロスサービスプリンシパル許可 **転送アクセスセッション (FAS) のサポート:** あり 転送アクセスセッション (FAS) は、AWS のサービス を呼び出すプリンシパルのアクセス許可を AWS のサービス のリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。 ## DynamoDB のサービスロール **サービスロールのサポート:** あり サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。 **警告** サービスロールの許可を変更すると、DynamoDB の機能が破損する可能性があります。DynamoDB が指示する場合以外は、サービスロールを編集しないでください。 ## DynamoDB 用のサービスリンクロール **サービスリンクロールのサポート:** あり サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。 サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。 ### DynamoDB でサポートされているサービスにリンクされたロール DynamoDB では、以下のサービスにリンクされたロールがサポートされています。 + DynamoDB は、サービスにリンクされたロール **AWSServiceRoleForDynamoDBReplication** を使用して、AWS リージョン全体のグローバルテーブルレプリケーションを行います。**AWSServiceRoleForDynamoDBReplication** サービスにリンクされたロールの詳細については、「[DynamoDB グローバルテーブルのセキュリティ](globaltables-security.md)」を参照してください。 + DynamoDB Accelerator (DAX) は、サービスにリンクされたロール **AWSServiceRoleForDAX** を使用して DAX クラスターを設定および維持します。**AWSServiceRoleForDAX** サービスにリンクされたロールの詳細については、「[DAX のサービスにリンクされた IAM ロールの使用](using-service-linked-roles.md)」を参照してください。 DynamoDB は、これらの DynamoDB サービスにリンクされたロールに加えて、Application Auto Scaling サービスを使用して、プロビジョニングされたキャパシティモードテーブルのスループット設定を自動的に管理します。Application Auto Scaling サービスは、サービスにリンクされたロール **AWSServiceRoleForApplicationAutoScaling\$1DynamoDBTable** を使用して、自動スケーリングが有効になっている DynamoDB テーブルのスループット設定を管理します。詳細については、「[Service-linked roles for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。 # Amazon DynamoDB のアイデンティティベースのポリシーの例 デフォルトでは、ユーザーおよびロールには、DynamoDB リソースを作成または変更するアクセス許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。 これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。 DynamoDB が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「サービス認可リファレンス」の「[Amazon DynamoDB のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html)」を参照してください。** **Topics** + [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices) + [DynamoDB コンソールの使用](#security_iam_id-based-policy-examples-console) + [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions) + [Amazon DynamoDB でのアイデンティティベースポリシーの使用](using-identity-based-policies.md) ## ポリシーに関するベストプラクティス ID ベースのポリシーは、ユーザーのアカウントで誰かが DynamoDB リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください: + **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。 + **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。 + **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。 + **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。 + **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。 IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。 ## DynamoDB コンソールの使用 Amazon DynamoDB コンソールにアクセスするには、許可の最小限のセットが必要です。これらのアクセス許可により、AWS アカウント の DynamoDB リソースの詳細をリストおよび表示できます。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。 AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスを許可します。 ユーザーとロールが引き続き DynamoDB コンソールを使用できるようにするには、エンティティに DynamoDB の `ConsoleAccess` または `ReadOnly` AWS マネージドポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。 ## 自分の権限の表示をユーザーに許可する この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` # Amazon DynamoDB でのアイデンティティベースポリシーの使用 このトピックでは、Amazon DynamoDB でのアイデンティティベースの AWS Identity and Access Management (IAM) ポリシーの使用についての説明と、例を示します。これらの例は、アカウント管理者が IAM アイデンティティ (ユーザー、グループ、およびロール) に許可ポリシーをアタッチし、それによって Amazon DynamoDB リソースに対するオペレーションを実行するための許可を付与する方法を示しています。 このセクションでは、次のトピックを対象としています。 + [Amazon DynamoDB コンソールの使用に必要な IAM 許可](#console-permissions) + [Amazon DynamoDB の AWS マネージド (事前定義) IAM ポリシー](#access-policy-examples-aws-managed) + [カスタマーマネージドポリシーの例](#access-policy-examples-for-sdk-cli) 以下は、アクセス権限ポリシーの例です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DescribeQueryScanBooksTable", "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Books" } ] } ``` ------ 上記のポリシーには、`us-west-2` AWS リージョンのテーブルで 3 つの DynamoDB アクション (`dynamodb:DescribeTable`、`dynamodb:Query`、`dynamodb:Scan`) を許可する 1 つのステートメントがあります。これは、`account-id` で指定される AWS アカウントで所有されています。`Resource` 値の *Amazon リソースネーム (ARN)* では、アクセス許可が適用されるテーブルを指定します。 ## Amazon DynamoDB コンソールの使用に必要な IAM 許可 ユーザーが DynamoDB コンソールを使用するには、AWS アカウントで DynamoDB リソースの使用を許可する最小限の許可セットが必要です。これらの DynamoDB 許可に加えて、コンソールでは次の許可が必要になります。 + メトリクスとグラフを表示する Amazon CloudWatch 許可。 + AWS Data PipelineDynamoDB データをエクスポートおよびインポートする アクセス許可。 + AWS Identity and Access Managementエクスポートおよびインポートに必要なロールにアクセスする アクセス許可。 + CloudWatch アラームがトリガーされるたびに通知する Amazon Simple Notification Service 許可。 + AWS LambdaDynamoDB Streams レコードを処理するための 許可。 これらの最小限必要なアクセス権限よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。[Amazon DynamoDB の AWS マネージド (事前定義) IAM ポリシー](#access-policy-examples-aws-managed) で説明されている通り、ユーザーが引き続き DynamoDB コンソールを使用できること、および `AmazonDynamoDBReadOnlyAccess`AWS マネージドポリシーがユーザーにアタッチされていることを確認してください。 AWS CLI または Amazon DynamoDB API のみを呼び出すユーザーには、最小限のコンソール許可を付与する必要はありません。 **注記** VPC エンドポイントを参照する場合、IAM アクション (dynamodb:DescribeEndpoints) を使用して、リクエストしている IAM プリンシパルの DescribeEndpoints API コールを認可する必要もあります。詳細については、「[エンドポイントに必要なポリシー](inter-network-traffic-privacy.md#inter-network-traffic-DescribeEndpoints)」を参照してください。 ## Amazon DynamoDB の AWS マネージド (事前定義) IAM ポリシー AWS は、 によって作成され管理されるスタンドアロンの IAM ポリシーが提供する多くの一般的ユースケースに対応します。AWSこれらの AWS 管理ポリシーは、一般的ユースケースに必要なアクセス権限を付与することで、どの権限が必要なのかをユーザーが調査する必要をなくすことができます。詳細については、*IAM ユーザーガイド*の「[AWS 管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。 アカウントのユーザーにアタッチ可能な以下の AWS マネージドポリシーは、DynamoDB 固有のもので、ユースケースシナリオ別にグループ化されます。 + **AmazonDynamoDBReadOnlyAccess** – AWS マネジメントコンソール を介して DynamoDB リソース への読み込み専用アクセスを許可します。 + **AmazonDynamoDBFullAccess** – AWS マネジメントコンソール を介して DynamoDB リソースへのフルアクセスを許可します。 IAM コンソールにサインインし、特定のポリシーを検索することで、これらの AWS マネージド許可ポリシーを確認できます。 **重要** ベストプラクティスは、ユーザー、ロール、またはそれらを必要とするグループに[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)を付与するカスタム IAM ポリシーを作成することです。 ## カスタマーマネージドポリシーの例 このセクションでは、さまざまな DynamoDB アクションの許可を付与するポリシー例を示しています。これらのポリシーは、AWS SDK または AWS CLI を使用しているときに機能します。コンソールを使用している場合は、コンソールに固有の追加許可を付与する必要があります。詳細については、「[Amazon DynamoDB コンソールの使用に必要な IAM 許可](#console-permissions)」を参照してください。 **注記** 以下のすべてのポリシー例では、AWS リージョンの 1 つを使用しており、架空のアカウント ID とテーブル名が含まれています。 例: + [テーブル上のすべての DynamoDB アクションに許可を付与する IAM ポリシー](grant-permissions-to-any-action-on-table.md) + [DynamoDB テーブルの項目に読み込み専用許可を付与する IAM ポリシー](read-only-permissions-on-table-items.md) + [特定の DynamoDB テーブルとそのインデックスへのアクセスを付与する IAM ポリシー](iam-policy-specific-table-indexes.md) + [DynamoDB テーブルに対するアクセスの読み込み、書き込み、更新、削除を行う IAM ポリシー](iam-policy-example-data-crud.md) + [同じ AWS アカウントで DynamoDB 環境を分離する IAM ポリシー](iam-policy-separate-environments.md) + [DynamoDB リザーブドキャパシティの購入を防止する IAM ポリシー](iam-prevent-purchase-reserved-capacity.md) + [DynamoDB ストリームのみの読み込みアクセスを付与する IAM ポリシー (テーブルを除く)](iam-policy-read-stream-only.md) + [AWS Lambda 関数が DynamoDB ストリームレコードへのアクセスを許可する IAM ポリシー](iam-policy-example-lamda-process-dynamodb-streams.md) + [DynamoDB アクセラレーター (DAX) クラスターへの読み込みおよび書き込みアクセスに関する IAM ポリシー](iam-policy-example-read-write-dax-access.md) 「*IAM ユーザーガイド*」には、[追加の DynamoDB 例が 3 つ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html)含まれています。 + [Amazon DynamoDB: 特定のテーブルへのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html) + [Amazon DynamoDB: 特定の列へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_columns.html) + [Amazon DynamoDB: Amazon Cognito ID に基づいて DynamoDB への行レベルのアクセスを許可する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.html) # テーブル上のすべての DynamoDB アクションに許可を付与する IAM ポリシー 以下のポリシーでは、`Books` というテーブルでの*すべて*の DynamoDB アクションの許可を付与します。`Resource` で指定されたリソース ARN は、特定の AWS リージョンのテーブルを識別します。`Resource` ARN のテーブル名 `Books` をワイルドカード文字 (\$1) で置き換えると、アカウント内の*すべて*のテーブルで*すべて*の DynamoDB アクションが許可されます。このポリシーまたは IAM ポリシーでワイルドカード文字を使用する前に、考えられるセキュリティへの影響を慎重に検討してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllAPIActionsOnBooks", "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ **注記** これは、ワイルドカード文字 (\$1) を使用して、*すべての*アクション (管理、データオペレーション、モニタリング、DynamoDB リザーブドキャパシティーの購入など) を許可する例です。代わりに、付与する各アクションと、そのユーザー、ロール、またはグループが必要とするアクションのみを明示的に指定することをお勧めします。 # DynamoDB テーブルの項目に読み込み専用許可を付与する IAM ポリシー 次の許可ポリシーは、`GetItem`、`BatchGetItem`、`Scan`、`Query`、および `ConditionCheckItem` DynamoDB アクションのみに許可を付与し、その結果、`Books` テーブルへの読み込み専用アクセスを設定します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadOnlyAPIActionsOnBooks", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ # 特定の DynamoDB テーブルとそのインデックスへのアクセスを付与する IAM ポリシー 以下のポリシーでは、`Books` という DynamoDB テーブルと、そのテーブルのすべてのインデックスに対するデータ変更アクションの許可を付与します。インデックスの動作の詳細については、「[DynamoDB でのセカンダリインデックスを使用したデータアクセス性の向上](SecondaryIndexes.md)」を参照してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AccessTableAllIndexesOnBooks", "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:ConditionCheckItem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books", "arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*" ] } ] } ``` ------ # DynamoDB テーブルに対するアクセスの読み込み、書き込み、更新、削除を行う IAM ポリシー アプリケーションが Amazon DynamoDB テーブル、インデックス、およびストリーミングのデータを作成、読み込み、更新、および削除できるようにする必要がある場合は、このポリシーを使用します。必要に応じて、AWS リージョン名、アカウント ID、 テーブル名またはワイルドカード文字 (\$1) に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBIndexAndStreamAccess", "Effect": "Allow", "Action": [ "dynamodb:GetShardIterator", "dynamodb:Scan", "dynamodb:Query", "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:ListStreams" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*", "arn:aws:dynamodb:us-west-2:123456789012:table/Books/stream/*" ] }, { "Sid": "DynamoDBTableAccess", "Effect": "Allow", "Action": [ "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem", "dynamodb:PutItem", "dynamodb:DescribeTable", "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" }, { "Sid": "DynamoDBDescribeLimitsAccess", "Effect": "Allow", "Action": "dynamodb:DescribeLimits", "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books", "arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*" ] } ] } ``` ------ このポリシーを拡張して、このアカウントのすべての AWS リージョンのすべての DynamoDB テーブルをカバーするには、リージョンとテーブル名にワイルドカード (\$1) を使用します。以下に例を示します。 ``` "Resource":[ "arn:aws:dynamodb:*:123456789012:table/*", "arn:aws:dynamodb:*:123456789012:table/*/index/*" ] ``` # 同じ AWS アカウントで DynamoDB 環境を分離する IAM ポリシー たとえば、各環境で、`ProductCatalog` という名前のテーブルを独自のバージョンで維持するとします。2 つの `ProductCatalog` テーブルを同じ AWS アカウントから作成する場合、許可の設定方法により、片方の環境での動作が他の環境に影響を与える可能性があります。例えば、同時制御プレーンオペレーション (`CreateTable` など) の数に対するクォータは AWS アカウントレベルで設定されます。 その結果、1 つの環境内の各アクションによって、もう一方の環境で利用可能なオペレーションの数が減少します。また、片方の環境内のコードが他の環境内のテーブルに偶然にアクセスしてしまう危険性もあります。 **注記** 本番ワークロードとテストワークロードを分離して、イベントの潜在的な「爆発半径」を制御する場合、ベストプラクティスは、テストワークロードと本番ワークロード用に別々の AWS アカウントを作成することです。詳細については、[AWS アカウントの管理および分離](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)を参照してください。 さらに、Amit と Alice という 2 人のデベロッパーが `ProductCatalog` テーブルをテストしているとします。デベロッパーごとに別々の AWS アカウントを作成する代わりに、デベロッパー間で同じテスト AWS アカウントを共有することができます。このテスト用アカウントでは、`Alice_ProductCatalog` や `Amit_ProductCatalog` など、対象のデベロッパーごとに、同じテーブルのコピーを作成できます。この場合、テスト環境用に作成した AWS アカウント内で、ユーザーの Alice と Amit を作成できます。次に、所有するテーブルに対して DynamoDB アクションを実行できるように、これらのユーザーに許可を付与することができます。 これらの IAM ユーザーの許可を付与するには、次のいずれかを実行します。 + 各ユーザーに別々のポリシーを作成し、各ポリシーをユーザーごとに個別にアタッチします。たとえば、以下のポリシーをユーザーである Alice にアタッチすることで、`Alice_ProductCatalog` テーブルに対する DynamoDB アクションへのアクセスをすべて許可することができます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllAPIActionsOnAliceTable", "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:DescribeContributorInsights", "dynamodb:RestoreTableToPointInTime", "dynamodb:ListTagsOfResource", "dynamodb:CreateTableReplica", "dynamodb:UpdateContributorInsights", "dynamodb:CreateBackup", "dynamodb:DeleteTable", "dynamodb:UpdateTableReplicaAutoScaling", "dynamodb:UpdateContinuousBackups", "dynamodb:TagResource", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:DescribeContinuousBackups", "dynamodb:BatchGetItem", "dynamodb:UpdateTimeToLive", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem", "dynamodb:UntagResource", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem", "dynamodb:DeleteTableReplica", "dynamodb:DescribeTimeToLive", "dynamodb:RestoreTableFromBackup", "dynamodb:UpdateTable", "dynamodb:DescribeTableReplicaAutoScaling", "dynamodb:GetShardIterator", "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:DescribeLimits", "dynamodb:ListStreams" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Alice_ProductCatalog/*" } ] } ``` ------ 次に、ユーザー Amit に対して、同様のポリシーを異なるリソース (`Amit_ProductCatalog` テーブル) で作成できます。 + 個々のユーザーにポリシーを付与する代わりに、IAM ポリシー変数を使用して単一のポリシーを記述し、グループに付与することができます。この例では、グループを作成し、そのグループにユーザー Alice とユーザー Amit の両者を追加する必要があります。次の例では、`${aws:username}_ProductCatalog` テーブルのすべての DynamoDB アクションを実行できる許可を付与します。ポリシーが評価されると、ポリシー変数 `${aws:username}` はリクエスターのユーザー名に置き換えられます。たとえば、Alice が項目の追加要求を送信する場合、Alice が `Alice_ProductCatalog` テーブルにアイテムを追加する場合にのみ、そのアクションが許可されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ActionsOnUserSpecificTable", "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_ProductCatalog" }, { "Sid": "AdditionalPrivileges", "Effect": "Allow", "Action": [ "dynamodb:ListTables", "dynamodb:DescribeTable", "dynamodb:DescribeContributorInsights" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/*" } ] } ``` ------ **注記** IAM ポリシー変数を使用する場合、ポリシーで明示的に IAM ポリシー言語の `2012-10-17` バージョンを指定する必要があります。IAM ポリシー言語のデフォルトバージョン (`2008-10-17`) では、ポリシー変数をサポートしていません。 通常のように具体的なテーブルをリソースとして特定する代わりに、ワイルドカード文字 (\$1) を使用して、すべてのテーブルに許可を付与することができます。次の例に示すように、テーブル名の先頭には、リクエストを行っているユーザーの名前が付きます。 ``` "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_*" ``` # DynamoDB リザーブドキャパシティの購入を防止する IAM ポリシー Amazon DynamoDB リザーブドキャパシティーでは、1 回限りの前払い料金を支払い、期間中、大幅な節約ができる最小使用レベルを支払う契約を結びます。AWS マネジメントコンソール を使用して、リザーブドキャパシティーを表示し、購入できます。ただし、組織のすべてのユーザーが、リザーブドキャパシティーを購入できないようにしたい場合があります。リザーブドキャパシティーの詳細については、[Amazon DynamoDB の料金](https://aws.amazon.com/dynamodb/pricing)を参照してください。 DynamoDB は、リザーブドキャパシティー管理へのアクセスを制御するために、次の API オペレーションを提供します。 + `dynamodb:DescribeReservedCapacity` – 現在有効なリザーブドキャパシティーの購入を返します。 + `dynamodb:DescribeReservedCapacityOfferings` – で現在提供されているリザーブドキャパシティープランについての詳細を返します。AWS + `dynamodb:PurchaseReservedCapacityOfferings` – リザーブドキャパシティーの実際の注文を実行します。 AWS マネジメントコンソール はこれらの API アクションを使用してリザーブドキャパシティーの情報を表示し、購入を行います。アプリケーションプログラムからこれらのオペレーションを呼び出すことはできません。オペレーションにはコンソールからのみアクセスできるためです。ただし、IAM 許可ポリシーでこれらのオペレーションへのアクセスを許可または拒否することができます。 以下のポリシーでは、ユーザーは AWS マネジメントコンソール を使用して、リザーブドキャパシティの購入およびサービスを表示できますが、新規購入は拒否されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowReservedCapacityDescriptions", "Effect": "Allow", "Action": [ "dynamodb:DescribeReservedCapacity", "dynamodb:DescribeReservedCapacityOfferings" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:*" }, { "Sid": "DenyReservedCapacityPurchases", "Effect": "Deny", "Action": "dynamodb:PurchaseReservedCapacityOfferings", "Resource": "arn:aws:dynamodb:us-west-2:123456789012:*" } ] } ``` ------ このポリシーでは、ワイルドカード文字 (\$1) を使用して、すべてのユーザーに説明許可を付与し、すべての DynamoDB リザーブドキャパシティーの購入を拒否することに注意してください。 # DynamoDB ストリームのみの読み込みアクセスを付与する IAM ポリシー (テーブルを除く) テーブルで DynamoDB Streams を有効にすると、テーブル内の項目に加えられたすべての変更に関する情報をキャプチャします。詳細については、「」を参照してください[DynamoDB Streams の変更データキャプチャ](Streams.md) 場合によっては、アプリケーションが DynamoDB テーブルからデータを読み取らないようにする一方で、そのテーブルのストリーミングへのアクセスは許可したいことがあります。たとえば、項目の更新が検出されたときにストリーミングをポーリングし、Lambda 関数をコールして、追加の処理を実行するよう AWS Lambda を設定できます。 DynamoDB Streams へのアクセスを制御するために、以下のアクションを使用できます。 + `dynamodb:DescribeStream` + `dynamodb:GetRecords` + `dynamodb:GetShardIterator` + `dynamodb:ListStreams` 次のポリシー例では、`GameScores` という名前のテーブルでストリーミングにアクセスする許可をユーザーに付与します。ARN のワイルドカード文字 (\$1) は、そのテーブルに関連付けられた任意のストリーミング ID に一致します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AccessGameScoresStreamOnly", "Effect": "Allow", "Action": [ "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:ListStreams" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/stream/*" } ] } ``` ------ このポリシーは `GameScores` テーブルのストリーミングへのアクセスを付与しますが、テーブル自体へのアクセスは付与しないことに注意してください。 # AWS Lambda 関数が DynamoDB ストリームレコードへのアクセスを許可する IAM ポリシー DynamoDB Streams のイベントに基づいて特定のアクションを実行する場合、それらのイベントによってトリガーされる AWS Lambda 関数を書き込むことができます。このような Lambda 関数には、DynamoDB Streams からデータを読み込む許可が必要です。DynamoDB Streams で Lambda を使用する詳細方法については、[DynamoDB Streams と AWS Lambda のトリガー](Streams.Lambda.md) を参照してください。 Lambda に許可を付与するには、Lambda 関数の IAM ロール (実行ロールともいう) に関連付けられた許可ポリシーを使用します｡ Lambda 関数の作成時に、このポリシーを指定します。 たとえば、次の許可ポリシーを実行ロールに関連付けて、リストされた DynamoDB Streams アクションを実行する許可を Lambda に付与できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "APIAccessForDynamoDBStreams", "Effect": "Allow", "Action": [ "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:DescribeStream", "dynamodb:ListStreams" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/stream/*" } ] } ``` ------ 詳細については、*AWS Lambda デベロッパーガイド*の [AWS Lambda 許可](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html)を参照してください。 # DynamoDB アクセラレーター (DAX) クラスターへの読み込みおよび書き込みアクセスに関する IAM ポリシー 次のポリシーは、DynamoDB アクセラレーター (DAX) クラスターへの読み込み、書き込み、更新、および削除アクセスを許可しますが、関連する DynamoDB テーブルへのアクセスは許可しません。このポリシーを使用するには、AWS リージョン名、アカウント ID、DAX クラスターの名前に置き換えます。 **注記** このポリシーは、DAX クラスターへのアクセスを許可しますが、関連する DynamoDB テーブルへのアクセスは許可しません。DAX クラスターに、ユーザーに代わって DynamoDB テーブルでこれらの同じオペレーションを実行するための正しいポリシーがあることを確認してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AmazonDynamoDBDAXDataOperations", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:PutItem", "dax:ConditionCheckItem", "dax:BatchGetItem", "dax:BatchWriteItem", "dax:DeleteItem", "dax:Query", "dax:UpdateItem", "dax:Scan" ], "Resource": "arn:aws:dax:eu-west-1:123456789012:cache/MyDAXCluster" } ] } ``` ------ このポリシーを拡張して、アカウントのすべての AWS リージョンの DAX アクセスをカバーするには、リージョン名にワイルドカード文字 (\$1) を使用します。 ``` "Resource": "arn:aws:dax:*:123456789012:cache/MyDAXCluster" ``` # Amazon DynamoDB アイデンティティとアクセスのトラブルシューティング 次の情報は、DynamoDB と IAM の使用に伴って発生する可能性がある一般的な問題の診断や解決に役立ちます。 **Topics** + [DynamoDB でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions) + [iam:PassRole を実行する権限がない](#security_iam_troubleshoot-passrole) + [自分の AWS アカウント 以外のユーザーに DynamoDB リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access) ## DynamoDB でアクションを実行する権限がない AWS マネジメントコンソール から、アクションを実行することが認可されていないと通知された場合、管理者に問い合わせ、サポートを依頼する必要があります。担当の管理者はお客様のユーザー名とパスワードを発行した人です。 以下のエラー例は、`mateojackson` ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `aws:GetWidget` 許可がないという場合に発生します。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: aws:GetWidget on resource: my-example-widget ``` この場合、Mateo は、`aws:GetWidget` アクションを使用して `my-example-widget` リソースにアクセスできるように、管理者にポリシーの更新を依頼します。 ## iam:PassRole を実行する権限がない `iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して DynamoDB にロールを渡せるようにする必要があります。 一部の AWS のサービス では、新しいサービスロールやサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。 以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して DynamoDB でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。 サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。 ## 自分の AWS アカウント 以外のユーザーに DynamoDB リソースへのアクセスを許可したい 他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。 詳細については、以下を参照してください。 + DynamoDB でこれらの特徴がサポートされるかどうかを確認するには、「[Amazon DynamoDB で IAM が機能する仕組み](security_iam_service-with-iam.md)」を参照してください。 + 所有している AWS アカウント 全体のリソースへのアクセス権を提供する方法については、*IAM ユーザーガイド* の [所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) を参照してください。 + サードパーティの AWS アカウント にリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[サードパーティが所有する AWS アカウント へのアクセス権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。 + ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。 + クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、「**IAM ユーザーガイド」の「[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。 # DynamoDB リザーブドキャパシティの購入を防止する IAM ポリシー Amazon DynamoDB リザーブドキャパシティーでは、1 回限りの前払い料金を支払い、期間中、大幅な節約ができる最小使用レベルを支払う契約を結びます。AWS マネジメントコンソール を使用して、リザーブドキャパシティーを表示し、購入できます。ただし、組織のすべてのユーザーが、リザーブドキャパシティーを購入できないようにしたい場合があります。リザーブドキャパシティーの詳細については、[Amazon DynamoDB の料金](https://aws.amazon.com/dynamodb/pricing)を参照してください。 DynamoDB は、リザーブドキャパシティー管理へのアクセスを制御するために、次の API オペレーションを提供します。 + `dynamodb:DescribeReservedCapacity` – 現在有効なリザーブドキャパシティーの購入を返します。 + `dynamodb:DescribeReservedCapacityOfferings` – で現在提供されているリザーブドキャパシティープランについての詳細を返します。AWS + `dynamodb:PurchaseReservedCapacityOfferings` – リザーブドキャパシティーの実際の注文を実行します。 AWS マネジメントコンソール はこれらの API アクションを使用してリザーブドキャパシティーの情報を表示し、購入を行います。アプリケーションプログラムからこれらのオペレーションを呼び出すことはできません。オペレーションにはコンソールからのみアクセスできるためです。ただし、IAM 許可ポリシーでこれらのオペレーションへのアクセスを許可または拒否することができます。 以下のポリシーでは、ユーザーは AWS マネジメントコンソール を使用して、リザーブドキャパシティの購入およびサービスを表示できますが、新規購入は拒否されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowReservedCapacityDescriptions", "Effect": "Allow", "Action": [ "dynamodb:DescribeReservedCapacity", "dynamodb:DescribeReservedCapacityOfferings" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:*" }, { "Sid": "DenyReservedCapacityPurchases", "Effect": "Deny", "Action": "dynamodb:PurchaseReservedCapacityOfferings", "Resource": "arn:aws:dynamodb:us-west-2:123456789012:*" } ] } ``` ------ このポリシーでは、ワイルドカード文字 (\$1) を使用して、すべてのユーザーに説明許可を付与し、すべての DynamoDB リザーブドキャパシティーの購入を拒否することに注意してください。 # 詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用 DynamoDB で許可を付与するときは、許可ポリシーを有効にする方法を決める条件を指定できます。 ## 概要 DynamoDB では、IAM ポリシー ([Amazon DynamoDB の Identity and Access Management](security-iam.md) を参照) を使用して許可を付与するとき、条件を指定することもできます。たとえば、以下のことが可能です。 + テーブル内またはセカンダリインデックスの特定の項目と属性に対する読み込み専用アクセスをユーザーに許可する許可を付与します。 + ユーザーのアイデンティティに基づいて、テーブルの特定の属性への書き込み専用アクセスのアクセス権限をユーザーに付与します。 DynamoDB では、次のセクションのユースケースに示すように、条件キーを使用して IAM ポリシーの条件を指定できます。 ### アクセス権限のユースケース DynamoDB API アクションへのアクセスを制御するだけでなく、個別のデータ項目と属性へのアクセスも制御できます。例えば、次の操作を実行できます。 + テーブルでアクセス権限を付与しますが、特定のプライマリキー値に基づいて、そのテーブル内の特定の項目へのアクセスを制限します。この例として、ゲーム用のソーシャルネットワーキングアプリケーションがあります。次の図に示すように、すべてのユーザーのゲームデータは 1 つのテーブルに保存されますが、いずれのユーザーも、自分が所有していないデータ項目にアクセスすることはできません。 ![\[ユーザーにテーブルレベルのアクセスを付与するが、特定のデータ項目へのアクセスを制限するユースケース。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/info-hiding-horizontal.png) + 属性のサブセットのみがユーザー表示されるように、情報を非表示にします。この例として、ユーザーの位置に基づいて、近くの空港の運航便データを表示するアプリケーションがあります。航空会社名、到着時間、出発時間、および運航便番号がすべて表示されます。ただし、次の図に示すように、パイロット名や乗客数などの属性は非表示になります。 ![\[ユーザーにデータのサブセットのみを表示し、データの特定の属性を非表示にするユースケース。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/info-hiding-vertical.png) このような種類のきめ細かなアクセス制御を実装するには、セキュリティ認証情報と関連する許可にアクセスするための条件を指定した IAM 許可ポリシーを書き込みます。次に、IAM コンソールを使用して作成する ユーザー、グループ、またはロールにそのポリシーを適用します。IAM ポリシーによって、テーブルの個別項目へのアクセス、その項目の属性へのアクセス、またはその両方へのアクセスを同時に制御できます。 必要に応じて、ウェブアイデンティティフェデレーションを使用して、Login with Amazon、Facebook、または Google によって認証されるユーザーによるアクセスを制御できます。詳細については、「」を参照してください[ウェブ ID フェデレーションの使用](WIF.md) IAM の `Condition` 要素を使用して、詳細なアクセスコントロールポリシーを実装できます。`Condition` 要素を許可ポリシーに追加することで、特定のビジネス要件に基づいて、DynamoDB テーブルとインデックスの項目と属性へのアクセスを許可または拒否できます。 次の動画では、IAM ポリシー条件を使用した DynamoDB でのきめ細かなアクセスコントロールについて説明します。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/LbEmo_yulb0?si=VTSlNHVocAEYwhJi/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/LbEmo_yulb0?si=VTSlNHVocAEYwhJi) ## DynamoDB でのきめ細かなアクセスコントロールを理解する DynamoDB でのきめ細かなアクセスコントロールにより、複数のレベルで正確なアクセス許可の境界を作成できます。 1. **項目レベルのアクセスコントロール:** 通常は、ID またはアクセス許可の範囲と一致する特定のキー値を含む項目のみにユーザーによるアクセスを制限します。 1. **属性レベルのアクセスコントロール:** ユーザーが表示または変更できる属性 (列) を制限し、機密情報を保護しながら、同じ項目内の非機密データへのアクセスを許可します。 1. **オペレーション固有のコントロール:** 実行するオペレーションのタイプに基づいて異なるアクセス許可ルールを適用します。 これらのコントロールは、DynamoDB 固有の条件キーを使用して IAM ポリシーを通じて実装されます。 ## 条件の指定: 条件キーの使用 AWS には、アクセス制御のために IAM をサポートするすべての AWS サービスに合わせて事前定義された一連の条件キー (AWS 全体に対する条件キー) が用意されています。たとえば、`aws:SourceIp` 条件キーを使用して、リクエスタの IP アドレスを確認してから、アクションの実行を許可できます。AWS 全体を対象とするキーの詳細およびリストについては、IAM ユーザーガイドの[使用可能な条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)を参照してください。 以下は、DynamoDB に適用される DynamoDB サービス固有の条件キーを示しています。 **`dynamodb:LeadingKeys`** テーブルの最初のキー属性、つまりパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 `LeadingKeys` は複数形になります。また、条件で `ForAllValues` を使用するときには、`LeadingKeys` 修飾子を使用する必要があります。 **`dynamodb:Select`** リクエストの `Select` パラメータを表します。`Select` には次のいずれかの値を指定できます。 + `ALL_ATTRIBUTES` + `ALL_PROJECTED_ATTRIBUTES` + `SPECIFIC_ATTRIBUTES` + `COUNT` 多くの場合、この条件キーはクエリおよびスキャンオペレーションに関連付けられますが、項目属性を返すすべての DynamoDB オペレーションに適用され、すべての API アクションで属性アクセスを制御するために不可欠です。この条件キーに StringEqualsIfExists または同様の制約を使用すると、この条件キーが適用されるオペレーションに制約が適用され、適用されないオペレーションでは制約が無視されます。 **`dynamodb:Attributes`** リクエストによってアクセスされる*最上位*属性のリストを表します。最上位属性は、それ自身かその入れ子の属性がリクエストパラメータで指定されている場合、リクエストによってアクセスされます。例えば、`"Name, Address.City"` の `ProjectionExpression` を指定する `GetItem` リクエストの場合、`dynamodb:Attributes` リストには「名前」と「住所」が含まれます。`Attributes` パラメータがきめ細かなアクセスコントロールポリシーで列挙されている場合は、`GetItem`、`Query`、`Scan` などの複数の API アクションで指定された属性へのアクセスが制限されるように、`ReturnValues` パラメータと `Select`パラメータも制限することを検討してください。 この条件は、レスポンスの属性ではなく、リクエストで指定された属性 (ProjectionExpression など) に対してのみ評価されます。リクエストに ProjectionExpression が指定されていない場合、ポリシーの属性制限に関係なく、すべての属性が返されます。属性アクセスを適切に保護する方法の詳細については、以下の「属性ベースの制限を確実に適用する」セクションを参照してください。 **`dynamodb:ReturnValues`** リクエストの `ReturnValues` パラメータを表します。API アクションに応じて、`ReturnValues` は次のいずれかの値になります。 + `ALL_OLD` + `UPDATED_OLD` + `ALL_NEW` + `UPDATED_NEW` + `NONE` **`dynamodb:ReturnConsumedCapacity`** リクエストの `ReturnConsumedCapacity` パラメータを表します。`ReturnConsumedCapacity` には次のいずれかの値を指定できます。 + `TOTAL` + `NONE` **`dynamodb:FirstPartitionKeyValues`** テーブルの最初のキー属性、つまり最初のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 `FirstPartitionKeyValues` は複数形になります。また、条件で `FirstPartitionKeyValues` を使用するときには、`ForAllValues` 修飾子を使用する必要があります。`FirstPartitionKeyValues` と `LeadingKeys` の使用は交換可能です。 **`dynamodb:SecondPartitionKeyValues`** `dynamodb:FirstPartitionKeyValues` と同様です。リソースの 2 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 `SecondPartitionKeyValues` は複数形になります。 **`dynamodb:ThirdPartitionKeyValues`** `dynamodb:FirstPartitionKeyValues` と同様です。リソースの 3 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 `ThirdPartitionKeyValues` は複数形になります。 **`dynamodb:FourthPartitionKeyValues`** `dynamodb:FirstPartitionKeyValues` と同様です。リソースの 4 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 `FourthPartitionKeyValues` は複数形になります。 ### 属性ベースの制限を確実に適用する 属性ベースの条件を使用して特定の属性へのアクセスを制限する場合は、これらの条件がどのように評価されるかを理解することが重要です。 + レスポンスの属性ではなく、**属性条件は、リクエストで指定された属性でのみ評価されます**。 + **ProjectionExpression を使用しない読み取りオペレーション** (GetItem、Query、Scan など) の場合、ポリシーの属性制限に関係なく、すべての属性が返されます。この機密データの潜在的な漏洩を防ぐには、属性条件 (`dynamodb:Attributes`) と特定の属性を必要とする条件 (`dynamodb:Select`) の両方を実装する必要があります。 + **書き込みオペレーション** (PutItem、UpdateItem、DeleteItem) の場合、ReturnValues パラメータは完全な項目を返すことができ、書き込みオペレーション自体がポリシーに準拠している場合でも、制限された属性が公開される可能性があります。この露出を防ぐには、ポリシーに属性条件 (`dynamodb:Attributes`) と ReturnValues (`dynamodb:ReturnValues`) の制限の両方を実装します。 ### ユーザーアクセスの制限 多くの IAM アクセス権限ポリシーでは、パーティションキーの値がユーザー識別子と一致するテーブルの項目へのアクセスのみをユーザーに許可します。たとえば、前述のゲームアプリケーションは、この方法でアクセスを制限し、ユーザーは自分のユーザー ID に関連付けらたゲームデータのみにアクセスできるようにします。IAM 置換変数 `${www.amazon.com:user_id}`、`${graph.facebook.com:id}`、および `${accounts.google.com:sub}` には、Login with Amazon、Facebook、および Google のユーザー識別子が格納されます。アプリケーションがこのようなアイデンティティプロバイダーのいずれかにログインし、この識別子を取得する方法については、「[ウェブ ID フェデレーションの使用](WIF.md)」を参照してください。 **重要** グローバルテーブルのレプリケーションを制限する場合、きめ細かなアクセスコントロールはサポートされていません。グローバルテーブルのレプリケーションに使用される DynamoDB [サービスプリンシパルまたはサービスにリンクされたロール](globaltables-security.md)にきめ細かなアクセスコントロールのポリシー条件を適用すると、グローバルテーブル内のレプリケーションが中断される可能性があります。 **注記** 以下のセクションの各例では、`Effect` 句を `Allow` に設定し、許可されるアクション、リソース、およびパラメータのみを指定します。IAM ポリシーで明示的に指定されたものへのアクセスだけが許可されます。 場合によっては、拒否ベースとなるようにこのポリシーを書き直すことができます。つまり、`Effect` 句を `Deny` に設定して、ポリシーのすべてのロジックを逆にします。ただし、拒否ベースのポリシーを DynamoDB で使用しないようお勧めします。このようなポリシーは、許可ベースのポリシーと比べて、正しく記述するのが難しいためです。また、DynamoDB API への将来の変更 (または、既存の API 入力への変更) が原因で、拒否ベースのポリシーが機能しなくなる可能性があります。 ### ポリシー例: きめ細かなアクセスコントロールのための IAM ポリシー条件の使用 このセクションでは、DynamoDB テーブルとインデックスに対してきめ細かなアクセス制御を実装するための一部のポリシーについて説明します。 **注記** すべての例で、us-west-2 リージョンを使用し、架空のアカウント ID を含めています。 #### 例 1。属性制限付きの基本的なパーティションキーベースのアクセスコントロール 例として、プレーヤーがさまざまなゲームを選択してプレイできるモバイルゲームアプリケーションを考えてみます。このアプリケーションでは、`GameScores` という名前の DynamoDB テーブルを使用して、高スコアなどのユーザーデータを記録します。テーブルの各項目は、ユーザー ID とユーザーがプレイしたゲームの名前で一意に識別されます。`GameScores` テーブルには、パーティションキー (`UserId`) およびソートキー (`GameTitle`) で構成されているプライマリキーがあります。ユーザーは、そのユーザー ID に関連付けられたゲームデータだけにアクセスできます。ゲームをプレイするユーザーは、`GameRole` という名前の IAM ロールに属する必要があります。このロールには、セキュリティポリシーが添付されています。 このアプリケーションのユーザーアクセス権限を管理するには、次のようなアクセス権限ポリシーを記述できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "UserId", "GameTitle", "Wins", "Losses", "TopScore", "TopScoreDateTime" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ `GameScores` テーブル (`Resource` 要素) の特定の DynamoDB アクション (`Action` 要素) に対する許可の付与に加えて、`Condition` 要素は、次のように許可を制限する DynamoDB に固有の次の条件キーを使用します。 + `dynamodb:LeadingKeys` – この条件キーにより、ユーザーはパーティションのキーバリューがユーザー ID に一致する項目にのみアクセスできます。この ID、`${www.amazon.com:user_id}` は、置換変数です。置換変数の詳細については、「[ウェブ ID フェデレーションの使用](WIF.md)」を参照してください。 + `dynamodb:Attributes` – この条件キーは指定された属性へのアクセスを制限し、許可ポリシーにリストされたアクションのみが、これらの属性の値を返すことができるようにします。さらに、`StringEqualsIfExists` 句は、アプリケーションが常に対象となる特定の属性のリストを提供し、すべての属性をリクエストできないようにします。 IAM ポリシーが評価されると、結果は必ず true (アクセス許可) または false (アクセス拒否) になります。`Condition` 要素のいずれかの部分が false の場合、ポリシー全体が false と評価され、アクセスは拒否されます。 **重要** `dynamodb:Attributes` を使用する場合、ポリシーでリストに記載されているテーブルとすべてのセカンダリインデックスについて、すべてのプライマリキー属性とインデックスキー属性の名前を指定する必要があります。指定しなかった場合、DynamoDB は、このキー属性を使用して、リクエストされたアクションを実行できません。 IAM ポリシードキュメントには、次の Unicode 文字のみを含めることができます。水平タブ (U\$10009)、ラインフィード (U\$1000A)、キャリッジリターン (U\$1000D)、および U\$10020～U\$100FF の範囲内の文字。 #### 例 2: 特定のパーティションのキー値を持つ項目へのアクセスを制限するアクセス許可の付与 以下の許可ポリシーは、`GamesScore` テーブルで一連の DynamoDB アクションに対する許可を付与します。このポリシーは `dynamodb:LeadingKeys` 条件キーを使用して、`UserID` パーティションキーの値が、このアプリケーション用の Login with Amazon の一意のユーザー ID と一致する項目のみでユーザーアクションを制限します。 **重要** `Scan` 用のアクセス権限は、アクションのリストに含まれていません。これは、`Scan` が主要なキーにかかわらずすべての項目を返すためです。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"FullAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] } ``` ------ **注記** ポリシー変数を使用する場合は、ポリシーでバージョン 2012-10-17 を明示的に指定する必要があります。アクセスポリシー言語のデフォルトバージョンは 2008−10−17 です。このバージョンでは、ポリシー変数をサポートしていません。 読み取りアクセスを実装するには、データを変更可能なアクションを削除します。次のポリシーでは、読み込み専用アクセスを提供するアクションだけが条件に追加されています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"ReadOnlyAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] } ``` ------ **重要** `dynamodb:Attributes` を使用する場合、ポリシーでリストに記載されているテーブルとあらゆるセカンダリインデックスについて、すべてのプライマリキー属性とインデックスキー属性の名前を指定する必要があります。指定しなかった場合、DynamoDB は、このキー属性を使用して、リクエストされたアクションを実行できません。 #### 例 3: テーブルの特定の属性へのアクセスを制限するアクセス許可の付与 次のアクセス権限ポリシーは、`dynamodb:Attributes` 条件キーを追加して、テーブルの 2 つの特定の属性のみへアクセスを許可します。この属性に対して、読み込み、書き込み、または条件付き書き込みまたはスキャンフィルタでの評価を実行できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToSpecificAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem", "dynamodb:Scan" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "UserId", "TopScore" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] } ``` ------ **注記** このポリシーでは、許可リスト手法を使用し、列挙された一連の属性へのアクセスを許可します。代わりに、他の属性へのアクセスを拒否する同等のポリシーを記述することもできますが、この拒否リスト手法はお勧めしません。ユーザーは、ウィキペディア (http://en.wikipedia.org/wiki/Principle\$1of\$1least\$1privilege) で説明されている最小権限の原則に従って、これらの拒否属性の名前を判別し、拒否属性を指定する代わりに、許可リストアプローチを使用して、許可されたすべての値を列挙することができます。 このポリシーでは、`PutItem`、`DeleteItem`、または `BatchWriteItem` は許可されません。これらのアクションでは常に前の項目全体が置き換えられ、アクセスが許可されていない属性の以前の値を、ユーザーが削除できる可能性があるためです。 アクセス権限ポリシーの `StringEqualsIfExists` 句により、以下を実施することができます。 + ユーザーが `Select` パラメータを指定する場合、その値は `SPECIFIC_ATTRIBUTES` である必要があります。この要件により、インデックスの射影からなど、API アクションが許可されていない属性を返さないようにします。 + ユーザーが `ReturnValues` パラメータを指定する場合、その値は、`NONE`、`UPDATED_OLD`、または `UPDATED_NEW` にする必要があります。これが必要なのは、`UpdateItem` アクションでは、置換する前に項目が存在するかどうかをチェックするために、および、リクエストされた場合に前の属性値を返すことができるように、暗黙的な読み込みオペレーションが実行されるためです。`ReturnValues` をこのように制限することで、確実にユーザーが許可された属性だけを読み込むまたは書き込むことができるようにします。 + `StringEqualsIfExists` 節により、許可されたアクションのコンテキストで、リクエストごとに `Select` または `ReturnValues` パラメータのいずれか 1 つだけを使用できるようにすることができます。 次に、このポリシーのバリエーションをいくつか示します。 + 読み込みアクションだけを許可するには、許可されるアクションのリストから `UpdateItem` を削除できます。残りのどのアクションも `ReturnValues` を受け付けないので、条件から `ReturnValues` を削除できます。また、`StringEqualsIfExists` パラメーターには必ず値 (特に指定のない限り、`StringEquals`) があるので、`Select` を `ALL_ATTRIBUTES` に変更できます。 + 書き込みアクションだけを許可するには、許可されるアクションのリストから、`UpdateItem` を除くすべてのアクションを削除します。`UpdateItem` では `Select` パラメーターを使用しないので、条件から `Select` を削除できます。また、`StringEqualsIfExists` パラメーターには必ず値 (特に指定のない限り、`StringEquals`) があるので、`ReturnValues` を `NONE` に変更する必要があります。 + 名前がパターンに一致するすべての属性を許可するには、`StringLike` ではなく `StringEquals` を使用し、複数文字パターン照合ワイルドカード文字 (\$1) を使用します。 #### 例 4: 特定の属性で更新を回避するアクセス許可の付与 以下のアクセス権限のポリシーでは、`dynamodb:Attributes` 条件キーによって識別される特定の属性のみを更新するようユーザーアクセスを制限します。`StringNotLike` 条件によって、アプリケーションが、`dynamodb:Attributes` 条件キーを使用して指定された属性を更新できないようになります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"PreventUpdatesOnCertainAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "Condition":{ "ForAllValues:StringNotLike":{ "dynamodb:Attributes":[ "FreeGamesAvailable", "BossLevelUnlocked" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] } ``` ------ 次の点に注意してください。 + `UpdateItem` アクションは、他の書き込みアクションと同じように、更新前の値と更新後の値を返すことができるように、項目への読み取りアクセスを必要とします。ポリシーでは、`dynamodb:ReturnValues` 条件キーを指定して、更新が許可される属性のみにアクセスするようアクションを制限します。条件キーは、リクエストの `ReturnValues` を制限して `NONE`、`UPDATED_OLD`、または `UPDATED_NEW` のみを指定し、`ALL_OLD` または `ALL_NEW` は含まれません。 + `StringEqualsIfExists` 演算子は、リクエストに `dynamodb:Select` または `dynamodb:ReturnValues` が存在する場合、指定された値と一致することを保証します。これにより、オペレーションが完全な項目を返すのを防ぐことができます。 + 属性の更新を制限するときは、どのデータを返すことができるかを制御して、保護された属性の情報開示を防ぐ必要があります。 + `PutItem` および `DeleteItem` アクションは項目全体を置き換えるため、アプリケーションは任意の属性を変更することができます。したがって、特定の属性のみを更新するようアプリケーションを制限するときは、それらの API 用のアクセス権限を付与しないようにします。 #### 例 5: インデックスで射影された属性のみのクエリを実行するアクセス許可の付与 以下の許可ポリシーでは、`dynamodb:Attributes` 条件キーを使用して、セカンダリインデックス (`TopScoreDateTimeIndex`) でクエリを許可します。また、このポリシーでは、インデックスに射影された特定の属性だけをリクエストするようクエリを制限します。 アプリケーションがクエリで属性のリストを指定するよう要求するには、ポリシーで `dynamodb:Select` 条件キーを指定して、DynamoDB `Query` アクションの `Select` パラメータが `SPECIFIC_ATTRIBUTES` であることを要求します。属性のリストは、`dynamodb:Attributes` 条件キーを使用して提供される特定のリストに制限されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"QueryOnlyProjectedIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "TopScoreDateTime", "GameTitle", "Wins", "Losses", "Attempts" ] }, "StringEquals":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ 次のアクセス権限ポリシーは、似ていますが、クエリでは、インデックスに射影されたすべての属性をリクエストする必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"QueryAllIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "StringEquals":{ "dynamodb:Select":"ALL_PROJECTED_ATTRIBUTES" } } } ] } ``` ------ #### 例 6: 特定の属性とパーティションキー値へのアクセスを制限するアクセス許可の付与 以下の許可ポリシーでは、特定の DynamoDB アクション (`Action` 要素で指定) をテーブルとテーブルインデックス (`Resource` 要素で指定) で許可します。このポリシーは、`dynamodb:LeadingKeys` 条件キーを使用して、パーティションキーの値がユーザーの Facebook ID に一致する項目のみにアクセス許可を制限します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToCertainAttributesAndKeyValues", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${graph.facebook.com:id}" ], "dynamodb:Attributes":[ "attribute-A", "attribute-B" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] } ``` ------ 次の点に注意してください。 + ポリシー (`UpdateItem`) によって許可された書き込みアクションでは、attribute-A または attribute-B のみを変更できます。 + ポリシーでは `UpdateItem` が許可されるため、アプリケーションは新しい項目を挿入でき、その非表示の属性は、新しい項目では null として表示されます。この属性が `TopScoreDateTimeIndex` に射影されている場合、テーブルからのフェッチを引き起こすクエリを防止するという利点がポリシーに追加されます。 + アプリケーションは、`dynamodb:Attributes` に列挙されている属性以外の属性を読み込むことができません。このポリシーにより、アプリケーションは、読み込みリクエストで `Select` パラメータを `SPECIFIC_ATTRIBUTES` に設定する必要があり、許可リストの属性だけをリクエストすることができます。書き込みリクエストの場合、アプリケーションは、`ReturnValues` を `ALL_OLD` または `ALL_NEW` に設定できません。また、他の属性に基づく条件付き書き込みオペレーションを実行できません。 #### 例 7: テーブルの特定の属性へのアクセスを制限するアクセス許可の拒否 次のポリシーは、機密属性へのアクセスを拒否し、射影式を省略してこの制限を回避できないようにします。これにより、`CustomerData` テーブルへの一般的なアクセスを許可しますが、`SSN` および `CreditCardNumber` 属性へのアクセスは明示的に拒否します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData" }, { "Effect":"Deny", "Action":[ "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData", "Condition":{ "ForAnyValue:StringEquals":{ "dynamodb:Attributes":[ "SSN", "CreditCardNumber" ] } } }, { "Effect":"Deny", "Action":[ "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData", "Condition":{ "StringNotEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ ## 関連トピック + [Amazon DynamoDB の Identity and Access Management](security-iam.md) + [DynamoDB API の許可: アクション、リソース、条件リファレンス](api-permissions-reference.md) # ウェブ ID フェデレーションの使用 多数のユーザーを対象とするアプリケーションを記述している場合、必要に応じて、*ウェブ ID フェデレーション*を使用して、認証と認可を実行できます。ウェブ ID フェデレーションは、個々の ユーザーを作成する必要性を排除します。代わりに、ユーザーは ID プロバイダーにサインインした後、一時的なセキュリティ資格情報を AWS Security Token Service (AWS STS) から取得できます。アプリケーションでは、この認証情報を使用して AWS サービスにアクセスできます。 ウェブアイデンティティフェデレーションでは、次のアイデンティティプロバイダーをサポートしています。 + Login with Amazon + Facebook + Google ## ウェブアイデンティティフェデレーションに関するその他のリソース ウェブアイデンティティフェデレーションの詳細を理解するのに、次のリソースが役に立ちます。 + AWS デベロッパーブログの「[Web Identity Federation using the AWS SDK for .NET](https://aws.amazon.com/blogs/developer/web-identity-federation-using-the-aws-sdk-for-net) 」の記事では、ウェブ ID フェデレーションを Facebookで使用する方法について説明しています。記事には、ウェブ ID を持つ ロールを想定する方法や、一時的なセキュリティ認証情報を使用して AWS リソースにアクセスする方法を示す C\$1 のコードスニペットが含まれています。 + [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) と [AWS Mobile SDK for Android](https://aws.amazon.com/sdkforandroid/) には、サンプルアプリが含まれています。このアプリケーションには、アイデンティティプロバイダーを呼び出す方法、そのプロバイダーからの情報を使用して、一時的なセキュリティ認証情報を取得および使用する方法を示すコードが含まれています。 + 記事「[Web Identity Federation with Mobile Applications](https://aws.amazon.com/articles/4617974389850313)」では、ウェブ ID フェデレーションについて説明し、ウェブ ID フェデレーションを使用して AWS リソースにアクセスする使用方法の例を挙げています。 ## ウェブ ID フェデレーションのポリシー例 DynamoDB でウェブ ID フェデレーションを使用する方法を示すには、[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) で導入された *GameScores* テーブルに再度アクセスしてください。次に、*GameScores* のプライマリキーを示します。 **** | テーブル名 | プライマリキーのタイプ | パーティションキーの名前と型 | ソートキーの名前と型 | | --- | --- | --- | --- | | GameScores (UserId、GameTitle、...) | 複合 | 属性名: UserId 型: 文字列 | 属性名: GameTitle 型: 文字列 | ここで、あるモバイルゲームアプリケーションがこのテーブルを使用し、そのアプリケーションでは、数千人、数百万人のユーザーをサポートする必要があるとします。この規模では、個別のアプリケーションユーザーを管理し、各ユーザーが *GameScores* テーブルの自分のデータにだけアクセスできることを確実にするのは非常に難しいです。多くのユーザーは、Facebook、Google、Login with Amazon などのサードパーティーの ID プロバイダーのアカウントを既に持っています。そのため、このようなプロバイダーのいずれかを利用して、認証タスクを行うことができます。 ウェブ ID フェデレーションを使用して認証を行うには、アプリケーションデベロッパーは、そのアプリケーションをアイデンティティプロバイダー（Login with Amazon など）に登録して、一意のアプリケーション ID を取得する必要があります。次に、デベロッパーはロールを作成する必要があります (この例では、このロールには *GameRole* という名前が付いています)。このロールには、IAM ポリシードキュメントを添付する必要があります。このドキュメントでは、アプリケーションが *GameScores* テーブルにアクセスできるように条件を指定します。 ユーザーは、ゲームをプレイするとき、ゲームアプリケーション内から Login with Amazon アカウントにサインインします。その後アプリケーションが AWS Security Token Service (AWS STS) を呼び出します。その際には Login with Amazon アプリ ID を指定し、*GameRole* でメンバーシップをリクエストします。AWS STS は一時的な AWS 認証情報をアプリケーションに返し、*GameRole* ポリシードキュメントに基づいて *GameScores* テーブルへのアクセスを許可します。 次の図は、これらの要素を組み合わせるとどのようになるかを示しています。 ![\[ゲームアプリケーションのワークフロー。アプリは Amazon ID と AWS STS を使用して、DynamoDB テーブルにアクセスするための一時的な認証情報を取得します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/wif-overview.png) **ウェブ ID フェデレーションの概要** 1. アプリケーションは、サードパーティのアイデンティティプロバイダーを呼び出して、ユーザーとアプリケーションを認証します。アイデンティティプロバイダーは、ウェブアイデンティティトークンをアプリケーションに返します。 1. アプリは AWS STS を呼び出し、ウェブアイデンティティトークンを入力として渡します。AWS STS は、アプリケーションを認可し、一時的な AWS アクセス認証情報をアプリケーションに渡します。アプリケーションは、IAM ロール (*GameRole*) を想定し、そのロールのセキュリティポリシーに従って AWS リソースにアクセスすることが許可されます。 1. アプリケーションは、DynamoDB をコールして、*GameScores* テーブルにアクセスします。アプリケーションは *GameRole* を想定しているので、そのロールに関連付けられたセキュリティポリシーの影響を受けます。ポリシードキュメントによって、ユーザーに属していないデータにアプリケーションはアクセスできません。 繰り返しになりますが、[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) に示されている *GameRole* のセキュリティポリシーは次のとおりです。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "UserId", "GameTitle", "Wins", "Losses", "TopScore", "TopScoreDateTime" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } ``` ------ `Condition` 節によって、アプリケーションに表示される *GameScores* の項目が決まります。Login with Amazon ID と `UserId` の `GameScores` パーティションキーの値を比較することで、これを行います。このポリシーに列挙されている DynamoDB アクションのいずれかを使用して処理できるのは、現在のユーザーに属する項目だけです。テーブルのその他の項目にはアクセスできません。さらに、ポリシーに列挙されている特定の属性にだけアクセスできます。 # ウェブ ID フェデレーションを使用するための準備 アプリケーションデベロッパーがアプリケーションにウェブ ID フェデレーションを使用する場合、次のステップに従います。 1. **デベロッパーとしてサードパーティーの ID プロバイダーにサインアップします。**次の外部リンクには、サポートされる ID プロバイダーへのサインアップに関する情報が記載されています。 + [Login with Amazon デベロッパーセンター](http://login.amazon.com/) + Facebook サイトの[登録](https://business.facebook.com/business/loginpage) + Google サイトの [OAuth 2.0 を使用して Google API にアクセスする](https://developers.google.com/accounts/docs/OAuth2) 1. **アプリケーションを ID プロバイダーに登録します。**登録すると、プロバイダーからアプリケーションに固有の ID が提供されます。複数のアイデンティティプロバイダーで機能するようにアプリケーションを構築する場合は、各プロバイダーからアプリケーション ID を取得する必要があります。 1. **1 つ以上の IAM ロールを作成します。**各アプリケーションのアイデンティティプロバイダーごとに 1 つのロールが必要です。たとえば、ユーザーが Login with Amazon を使用してサインインするアプリケーションで想定できるロール、ユーザーが Facebook を使用してサインインする同じアプリケーションの 2 つ目のロール、およびユーザーが Google を使用してサインインするアプリケーションの 3 つ目のロールを作成します。 ロール作成プロセスの中で、 ポリシーをロールにアタッチする必要があります。ポリシードキュメントでは、アプリケーションに必要な DynamoDB リソース、およびそれらのリソースにアクセスするための許可を定義する必要があります。 詳細については、*IAM ユーザーガイド*の[ウェブ ID フェデレーションについて](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)を参照してください。 **注記** AWS Security Token Service の代わりに、Amazon Cognito を使用できます。Amazon Cognito は、モバイルアプリケーションの一時的な認証情報を管理するためのおすすめサービスです。詳細については、*Amazon Cognito 開発者ガイド*」の「[認証情報の取得](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-credentials.html)」を参照してください。 ## DynamoDB コンソールを使用して IAM ポリシーを生成する DynamoDB コンソールでは、ウェブ ID フェデレーションで使用する IAM ポリシーを作成できます。作成するには、DynamoDB テーブルを選択し、ポリシーに含まれるアイデンティティプロバイダー、アクション、および属性を指定します。DynamoDB コンソールによって、IAM ロールにアタッチすることができるポリシーが生成されます。 1. AWS マネジメントコンソール マネジメントコンソールにサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。 1. ナビゲーションペインで [**テーブル**] を選択します。 1. テーブルの一覧で、IAM ポリシーを作成するテーブルを選択します。 1. **[アクション]** ボタン、**[アクセス制御ポリシーの作成]** の順に選択します。 1. ポリシーの ID プロバイダー、アクション、および属性を選択します。 すべての設定が正しいことを確認したら、**[ポリシーの生成]** を選択します。生成されたポリシーが表示されます。 1. **[ドキュメンテーションを参照]** を選択し、生成されたポリシーを IAM ロールにアタッチするために必要な手順に従います。 # ウェブ ID フェデレーションを使用するアプリケーションの記述 ウェブ ID フェデレーションを使用するには、アプリケーションで、作成した IAM ロールを引き受ける必要があります。その時点から、アプリケーションは、そのロールに関連付けられたアクセスポリシーに従います。 実行時、アプリケーションがウェブアイデンティティフェデレーションを使用する場合、次の手順に従う必要があります。 1. **サードパーティーの ID プロバイダーと認証を行います。**アプリケーションは、ID プロバイダーが提供するインターフェイスを使用してそのプロバイダーを呼び出す必要があります。ユーザーを認証するときの正確な方法は、プロバイダーおよびアプリケーションを実行しているプラットフォームによって異なります。一般的に、ユーザーがまだサインインしていない場合、アイデンティティプロバイダーはそのプロバイダーのサインインページを表示するように対処します。 アイデンティティプロバイダーはユーザーを認証した後、ウェブアイデンティティトークンをアプリケーションに返します。このトークンの形式は、プロバイダーによって異なりますが、通常は、非常に長い文字列です。 1. **一時的な AWS セキュリティ認証情報を取得します。**取得するために、アプリケーションは `AssumeRoleWithWebIdentity` リクエストを AWS Security Token Service (AWS STS) に送信します。このリクエストには次のものが含まれます。 + 前の手順からのウェブアイデンティティトークン + アイデンティティプロバイダーからのアプリケーション ID + このアプリケーションのこのアイデンティティプロバイダー用に作成した IAM ロールの Amazon リソースネーム (ARN) AWS STS は、一定の時間 (デフォルトでは、3,600 秒) 経過した後に失効する AWS セキュリティ認証情報のセットを返します。 次に、`AssumeRoleWithWebIdentity` で AWS STS アクションを実行するときのサンプルリクエストとレスポンスを示します。ウェブアイデンティティトークンは、Login with Amazon アイデンティティプロバイダーから取得しました。 ``` GET / HTTP/1.1 Host: sts.amazonaws.com Content-Type: application/json; charset=utf-8 URL: https://sts.amazonaws.com/?ProviderId=www.amazon.com &DurationSeconds=900&Action=AssumeRoleWithWebIdentity &Version=2011-06-15&RoleSessionName=web-identity-federation &RoleArn=arn:aws:iam::123456789012:role/GameRole &WebIdentityToken=Atza|IQEBLjAsAhQluyKqyBiYZ8-kclvGTYM81e...(remaining characters omitted) ``` ``` amzn1.account.AGJZDKHJKAUUSW6C44CHPEXAMPLE AQoDYXdzEMf//////////wEa8AP6nNDwcSLnf+cHupC...(remaining characters omitted) 8Jhi60+EWUUbbUShTEsjTxqQtM8UKvsM6XAjdA== 2013-10-01T22:14:35Z 06198791C436IEXAMPLE arn:aws:sts::123456789012:assumed-role/GameRole/web-identity-federation AROAJU4SA2VW5SZRF2YMG:web-identity-federation c265ac8e-2ae4-11e3-8775-6969323a932d ``` 1. **AWSリソースにアクセスする** AWS STS からのレスポンスには、DynamoDB リソースにアクセスするためにアプリケーションに必要な情報が格納されています。 + `AccessKeyID`、`SecretAccessKey`、および `SessionToken` フィールドには、このユーザーとこのアプリケーションにのみ有効なセキュリティ認証情報が入っています。 + `Expiration` フィールドは、この認証情報の時間制限を示します。この時間を経過すると、認証情報は無効になります。 + `AssumedRoleId` フィールドには、アプリケーションによって想定されたセッション固有の IAM ロールの名前が含まれています。アプリケーションは、このセッションの期間中、IAM ポリシードキュメントのアクセス制御に従います。 + `SubjectFromWebIdentityToken` フィールドには、この特定のアイデンティティプロバイダー用の IAM ポリシー変数に表示される一意の ID が含まれています。次に、サポートされるプロバイダーの IAM ポリシー変数と、その値の例を示します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/WIF.RunningYourApp.html) このポリシー変数が使用される IAM ポリシーの例については、[ポリシー例: きめ細かなアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md#FGAC_DDB.Examples) を参照してください。 AWS STS が一時的なアクセス認証情報を生成する詳しい方法については、*IAM ユーザーガイド*の[一時的なセキュリティ認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)を参照してください。 # DynamoDB API の許可: アクション、リソース、条件リファレンス [Amazon DynamoDB の Identity and Access Management](security-iam.md) を設定し、IAM アイデンティティにアタッチできる許可ポリシー (アイデンティティベースのポリシー) を書き込む場合は、リファレンスとして [IAM ユーザーガイド*の *Amazon DynamoDB のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html)リストを使用できます。このページは、各 DynamoDB API オペレーション、アクションを実行するための許可を付与できる対応するアクション、および許可を付与できる AWS リソースを示しています。ポリシーの `Action` フィールドでアクションを指定し、ポリシーの `Resource` フィールドでリソースの値を指定します。 DynamoDB ポリシーで AWS 全体の条件キーを使用して、条件を表現することができます。AWS 全体を対象とするすべてのキーのリストについては、*IAM ユーザーガイド*の [IAM JSON ポリシーエレメントリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)を参照してください。 AWS 全体を対象とする条件キーに加え、DynamoDB には条件内で使用可能な独自の固有キーもあります。詳細については、「」を参照してください[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) ## 関連トピック + [Amazon DynamoDB の Identity and Access Management](security-iam.md) + [詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) # DynamoDB の業界別のコンプライアンス検証 AWS のサービスが特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照して、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) を参照してください。 AWS Artifact を使用して、サードパーティの監査レポートをダウンロードできます。詳細については、「[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」「」を参照してください。 AWS のサービスを使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。AWS のサービス を使用する際のコンプライアンス責任の詳細については、「[AWS セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。 # Amazon DynamoDB での耐障害性と災害対策 AWS のグローバルインフラストラクチャは AWS リージョンとアベイラビリティーゾーンを中心として構築されます。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立し隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。 データまたはアプリケーションを遠方でレプリケートする必要がある場合は、AWS ローカルリージョンを使用します。AWS ローカルリージョンは、既存の AWS リージョンを補完するように設計された単一のデータセンターです。すべての AWS リージョンと同じように、AWS ローカルリージョンは他の AWS リージョンから完全に分離されています。 AWS リージョンとアベイラビリティーゾーンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。 Amazon DynamoDB は、リージョン内の 3 つのアベイラビリティーゾーンにデータを自動的にレプリケートし、組み込みの高い耐久性と 99.99% の可用性 SLA を提供します。さらに、DynamoDB は、データの耐障害性とバックアップのニーズに対応できるように複数の機能を提供しています。 **オンデマンドバックアップと復元** DynamoDB には、オンデマンドバックアップ機能があります。この機能により、長期間の保存とアーカイブのために、テーブルの完全なバックアップを作成できます。詳細については、「[DynamoDB のオンデマンドバックアップおよび復元](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup-and-Restore.html)」を参照してください。 **ポイントインタイムリカバリ** ポイントインタイムリカバリを使用することで、DynamoDB テーブルを偶発的な書き込みや削除のオペレーションから保護できます。ポイントインタイムリカバリを有効化すれば、オンデマンドバックアップの作成、維持、スケジュールを心配する必要はありません。詳細については、「[DynamoDB のポイントインタイムリカバリ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-in-time-recovery.html)」を参照してください。 **AWS リージョン間でのグローバルテーブルの同期** DynamoDB では、一貫性のある高速パフォーマンスを維持しながら、スループットとストレージの要件を処理できるように、テーブルのデータとトラフィックが十分な数のサーバーに自動的に分散されます。また、すべてのデータをソリッドステートディスク (SSD) に保存し、AWS リージョン内の複数のアベイラビリティーゾーン間で自動的にレプリケートするため、組み込みの高い可用性とデータ堅牢性が実現します。グローバルテーブルを使用して、DynamoDB テーブルを AWS リージョン間で同期させることができます。 # Amazon DynamoDB のインフラストラクチャセキュリティ マネージドサービスとして、Amazon DynamoDB は、AWS Well-Architected フレームワークにある[インフラストラクチャ保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)で説明されている AWS グローバルネットワークセキュリティ手順によって保護されます。 AWS が公開した API コールを使用して、ネットワーク経由で DynamoDB にアクセスします。クライアントは TLS (Transport Layer Security) バージョン 1.2 または 1.3 を使用できます。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもサポートしている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。また、リクエストは、アクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。 DynamoDB 用の 仮想プライベートクラウド (VPC) エンドポイントを使用することで、VPC 内の Amazon EC2 インスタンスがパブリックインターネットにさらされることなく、プライベート IP アドレスを使用して DynamoDB にアクセスできるようになります。詳細については、「」を参照してください[Amazon VPC エンドポイントを使用して DynamoDB にアクセスする](#vpc-endpoints-dynamodb) ## Amazon VPC エンドポイントを使用して DynamoDB にアクセスする セキュリティ上の理由から、多くの AWS ユーザーがアプリケーションを Amazon Virtual Private Cloud 環境 (Amazon VPC) 内で実行しています。Amazon VPC を使用すると、Amazon EC2 インスタンスを仮想プライベートクラウドで作成できます。そのため、パブリックインターネットなどの他のネットワークから論理的に分離されます。Amazon VPC を使用すると、IP アドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイ、セキュリティ設定を適切に管理できます。 **注記** 2013 年 12 月 4 日以降に AWS アカウントを作成した場合は、各 AWS リージョンにデフォルトの VPC が用意されています。デフォルトの VPC は、使用できる状態になっています。追加で設定手順を実行することなく、すぐに利用開始できます。 詳細については、*Amazon VPC ユーザーガイド*の「[デフォルト VPC とデフォルトサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)」を参照してください。 パブリックインターネットにアクセスするには、VPC にインターネットゲートウェイ (VPC をインターネットに接続する仮想ルーター) が必要です。これにより、VPC 内の Amazon EC2 で実行されているアプリケーションで、Amazon DynamoDB などのインターネットリソースにアクセスすることが可能になります。 デフォルトでは、DynamoDB との通信において、SSL/TLS 暗号化を使用してネットワークトラフィックを保護する HTTPS プロトコルが使用されます。次の図は、VPC 内の Amazon EC2 インスタンスから DynamoDB にアクセスするために、VPC エンドポイントではなくインターネットゲートウェイを使用する例を示しています。 ![\[ルーター、インターネットゲートウェイ、およびインターネットを経由して DynamoDB にアクセスする Amazon EC2 インスタンスを示すワークフロー図。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/ddb-no-vpc-endpoint.png) 多くのお客様が、パブリックインターネット間のデータ送受信に関して、プライバシーとセキュリティに関する正当な懸念を抱いています。これらの懸念を解決するために、仮想プライベートネットワーク (VPN) を使用して、すべての DynamoDB ネットワークトラフィックをお客様の企業ネットワークのインフラストラクチャ経由でルーティングできます。ただし、このアプローチでは、帯域幅や可用性の課題が生じる場合があります。 DynamoDB 用の VPC エンドポイントでは、これらの課題は軽減されます。DynamoDB 用の *VPC エンドポイント*を使用すると、VPC 内の Amazon EC2 インスタンスがパブリックインターネットにさらされることなく、プライベート IP アドレスを使用して DynamoDB にアクセスできるようになります。EC2 インスタンス にパブリック IP アドレスは必要ありません。また、VPC にインターネットゲートウェイ、NAT デバイス、仮想プライベートゲートウェイは不要です。DynamoDB へのアクセスを制御するには、エンドポイントのポリシーを使用します。VPC と AWS サービス間のトラフィックは、Amazon ネットワークを離れません。 **注記** パブリック IP アドレスを使用する場合でも、AWS でホストされているインスタンスとサービスの間で発生するすべての VPC 通信は、AWS ネットワーク内でのプライベートな通信となります。AWS ネットワークから発信され、送信先が AWS ネットワーク上のパケットは、AWS 中国リージョンとの送受信されるトラフィックを除き、AWS グローバルネットワークに残ります。 DynamoDB 用の VPC エンドポイントを作成する際、リージョン内の DynamoDB エンドポイント (例: *dynamodb.us-west-2.amazonaws.com*) に対するリクエストはすべて、Amazon ネットワーク内のプライベートの DynamoDB エンドポイントにルーティングされます。VPC 内の EC2 インスタンスで実行されているアプリケーションを変更する必要はありません。エンドポイント名は変わりませんが、DynamoDB へのルートは Amazon ネットワーク内に完全にとどまります。パブリックインターネットにアクセスすることはありません。 次の図は、VPC 内の EC2 インスタンスが VPC エンドポイントを使用して DynamoDB にアクセスする様子を示しています。 ![\[ルーターと VPC エンドポイントのみを経由して DynamoDB にアクセスする EC2 インスタンスを示すワークフロー図。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/ddb-yes-vpc-endpoint.png) 詳細については、「[チュートリアル: DynamoDB 用の VPC エンドポイントを使用する](#vpc-endpoints-dynamodb-tutorial)」を参照してください。 ### Amazon VPC エンドポイントと DynamoDB の共有 VPC サブネットのゲートウェイエンドポイントから DynamoDB サービスにアクセスできるようにするには、その VPC サブネットに対する所有者アカウントのアクセス許可が必要です。 VPC サブネットのゲートウェイエンドポイントに DynamoDB へのアクセスを許可すると、そのサブネットへのアクセス権を持つすべての AWS アカウントが DynamoDB を使用できます。つまり、VPC サブネット内のすべてのアカウントユーザーは、アクセス権が付与されている対象のすべての DynamoDB テーブルを使用できます。これには、VPC サブネットとは異なるアカウントに関連付けられた DynamoDB テーブルが含まれます。ただし、VPC サブネットの所有者は、独自の裁量により、サブネット内の特定のユーザーに対して、ゲートウェイエンドポイント経由での DynamoDB サービスの使用を制限できます。 ### チュートリアル: DynamoDB 用の VPC エンドポイントを使用する このセクションでは、DynamoDB 用の VPC エンドポイントの設定および使用について説明します。 **Topics** + [ステップ 1: Amazon EC2 インスタンスを起動する](#vpc-endpoints-dynamodb-tutorial.launch-ec2-instance) + [ステップ 2: Amazon EC2 インスタンスを設定する](#vpc-endpoints-dynamodb-tutorial.configure-ec2-instance) + [ステップ 3: DynamoDB 用の VPC エンドポイントを作成する](#vpc-endpoints-dynamodb-tutorial.create-endpoint) + [ステップ 4: (オプション) クリーンアップする](#vpc-endpoints-dynamodb-tutorial.clean-up) #### ステップ 1: Amazon EC2 インスタンスを起動する このステップでは、デフォルトの Amazon VPC で Amazon EC2 インスタンスを起動します。その後、DynamoDB 用の VPC エンドポイントを作成して使用できます。 1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。 1. **[Launch Instance]** (インスタンスを起動) を選択して、以下を実行します。 ステップ 1: Amazon マシンイメージ (AMI) の選択 + AMI のリストの上部で [**Amazon Linux AMI**] に移動し、[**選択**] を選びます。 ステップ 2: インスタンスタイプを選択する + インスタンスタイプのリストの上部で、[**t2.micro**] を選択します。 + [**次のステップ: インスタンスの詳細の設定**] を選択します。 ステップ 3: インスタンスの詳細を設定する + [**ネットワーク**] に移動し、デフォルトの VPC を選択します。 [**次の手順: ストレージの追加**] を選択します。 ステップ 4: ストレージを追加する + [**Next: Tag Instance**] を選択してこのステップをスキップします。 ステップ 5: インスタンスをタグ付けする + [**次のステップ: セキュリティグループの設定**] を選択してこのステップをスキップします。 ステップ 6: セキュリティグループを設定する + **[Select an existing security group]** (既存のセキュリティグループの選択) を選択します。 + セキュリティグループのリストで、[**default (デフォルト)**] を選択します。これは VPC のデフォルトのセキュリティグループです。 + **[Next: Review and Launch]** (次のステップ: 確認と起動) を選択します。 ステップ 7: インスタンス起動の確認 + **[Launch]** (起動する) を選択します。 1. [**既存のキーペアを選択するか、新しいキーペアを作成します。**] ウィンドウで、次のいずれかを実行します。 + Amazon EC2 キーペアがない場合は、**[Create a new key pair]** (新しいキーペアの作成) を選択して指示に従います。プライベートキーファイル (*.pem* ファイル) をダウンロードするよう求められます。このファイルは、後で Amazon EC2 インスタンスにログインする際に必要になります。 + 既存の Amazon EC2 キーペアがすでにある場合は、**[Select a key pair]** (キーペアの選択) を選択して、リストからキーペアを選択します。Amazon EC2 インスタンスにログインするには、既にプライベートキーファイル (*.pem* ファイル) が利用可能になっている必要があります。 1. キーペアを設定してある場合は、[**Launch Instances**] (インスタンスの起動) を選択します。 1. Amazon EC2 コンソールのホームページに戻り、起動したインスタンスを選択します。下のペインの **[Description]** (説明) タブで、インスタンスの **[Public DNS]** (パブリック DNS) を見つけます。例: `ec2-00-00-00-00.us-east-1.compute.amazonaws.com`。 このパブリック DNS 名をメモします。パブリック DNS 名は、このチュートリアル ([ステップ 2: Amazon EC2 インスタンスを設定する](#vpc-endpoints-dynamodb-tutorial.configure-ec2-instance)) の次のステップで必要になります。 **注記** Amazon EC2 インスタンスが使用できるようになるまで数分かかります。次のステップに行く前に、**[Instance State]** (インスタンスの状態) が `running` で、その **[Status Checks]** (ステータスチェック) がすべてパスしていることを確認します。 #### ステップ 2: Amazon EC2 インスタンスを設定する Amazon EC2 インスタンスが使用できるようになったら、そのインスタンスにログインして、最初に使用できるように準備できます。 **注記** 次の手順は、Linux を実行するコンピュータから Amazon EC2 インスタンスに接続していることを想定しています。その他の接続方法については、「Amazon EC2 ユーザーガイド」の「[Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)」を参照してください。 1. Amazon EC2 インスタンスへのインバウンド SSH トラフィックを認可する必要があります。これを行うには、新しい EC2 セキュリティグループを作成し、そのセキュリティグループを EC2 インスタンスに割り当てます。 1. ナビゲーションペインで、[**Security Groups**] を選択します。 1. [**Create Security Group** (セキュリティグループの作成)] を選択します。[**セキュリティグループを作成**] ウィンドウで以下を行います。 + **[Security group name]** (セキュリティグループ名) — セキュリティグループの名前を入力します。例: `my-ssh-access` + **[Description]** (説明) — セキュリティグループの簡単な説明を入力します。 + **VPC** — デフォルトの VPC を選択します。 + **[Security group rules]** (セキュリティグループのルール) セクションで、**[Add Rule]** (ルールの追加) を選択して、次の操作を行います + **[Type]** (タイプ) — SSH を選択します。 + **[Source]** (ソース) — My IP を選択します。 すべての設定が正しいことを確認したら、[**作成**] を選択します。 1. ナビゲーションペインで、[**インスタンス**] を選択します。 1. [ステップ 1: Amazon EC2 インスタンスを起動する](#vpc-endpoints-dynamodb-tutorial.launch-ec2-instance) で起動した Amazon EC2 インスタンスを選択します。 1. **[Actions]** (アクション)、**[Networking]** (ネットワーキング)、**[Change Security Groups]** (セキュリティグループの変更) の順に選択します。 1. **[Change Security Groups]** (セキュリティグループの変更) で、この手順で先に作成したセキュリティグループを選択します (例: `my-ssh-access`)。既存の `default` のセキュリティグループも選択する必要があります。すべての設定が正しいことを確認したら、**[Assign Security Groups]** (セキュリティグループの割り当て) を選択します。 1. 次の例のように、`ssh` コマンドを使用して Amazon EC2 インスタンスにログインします。 ``` ssh -i my-keypair.pem ec2-user@public-dns-name ``` プライベートキーファイル (*.pem* ファイル) とインスタンスのパブリック DNS 名を指定する必要があります。(「[ステップ 1: Amazon EC2 インスタンスを起動する](#vpc-endpoints-dynamodb-tutorial.launch-ec2-instance)」を参照してください)。 ログイン ID は `ec2-user` です。パスワードは不要です。 1. 次の例に示すように、AWS 認証情報を設定します。プロンプトが表示されたら、AWS アクセスキー ID、シークレットキー、デフォルトのリージョン名を入力します。 ``` aws configure ``` ``` AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: us-east-1 Default output format [None]: ``` これで、DynamoDB 用の VPC エンドポイントを作成する準備ができました。 #### ステップ 3: DynamoDB 用の VPC エンドポイントを作成する このステップでは、DynamoDB 用の VPC エンドポイントを作成し、テストを行い正常に動作することを確認します。 1. 開始する前に、パブリックエンドポイントを使用して DynamoDB と通信できることを確認します。 ``` aws dynamodb list-tables ``` 出力では、現在所有している DynamoDB テーブルのリストが表示されます。(テーブルがない場合、リストは空になります。)。 1. DynamoDB が、現在の AWS リージョンで VPC エンドポイントを作成するために利用可能なサービスであることを確認します。(コマンドは太字で示され、その後に出力例が続きます。) ``` aws ec2 describe-vpc-endpoint-services ``` ``` { "ServiceNames": [ "com.amazonaws.us-east-1.s3", "com.amazonaws.us-east-1.dynamodb" ] } ``` 出力例では、DynamoDB が利用可能なサービスの 1 つであるため、VPC エンドポイントの作成を続行できます。 1. VPC 識別子を決定します。 ``` aws ec2 describe-vpcs ``` ``` { "Vpcs": [ { "VpcId": "vpc-0bbc736e", "InstanceTenancy": "default", "State": "available", "DhcpOptionsId": "dopt-8454b7e1", "CidrBlock": "172.31.0.0/16", "IsDefault": true } ] } ``` 出力例では、VPC ID は `vpc-0bbc736e` です。 1. VPC エンドポイントを作成します。`--vpc-id` パラメータで、前のステップの VPC ID を指定します。`--route-table-ids` パラメータを使用して、エンドポイントをルートテーブルに関連付けます。 ``` aws ec2 create-vpc-endpoint --vpc-id vpc-0bbc736e --service-name com.amazonaws.us-east-1.dynamodb --route-table-ids rtb-11aa22bb ``` ``` { "VpcEndpoint": { "PolicyDocument": "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":\"*\",\"Action\":\"*\",\"Resource\":\"*\"}]}", "VpcId": "vpc-0bbc736e", "State": "available", "ServiceName": "com.amazonaws.us-east-1.dynamodb", "RouteTableIds": [ "rtb-11aa22bb" ], "VpcEndpointId": "vpce-9b15e2f2", "CreationTimestamp": "2017-07-26T22:00:14Z" } } ``` 1. VPC エンドポイント経由で DynamoDB にアクセスできることを確認します。 ``` aws dynamodb list-tables ``` 必要に応じて、DynamoDB 用の他の AWS CLI コマンドを試すことができます。詳細については、[AWS CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/)を参照してください。 #### ステップ 4: (オプション) クリーンアップする このチュートリアルで作成したリソースを削除する場合は、次の手順に従ってください。 **DynamoDB 用の VPC エンドポイントを削除するには** 1. Amazon EC2 インスタンスにログインします。 1. VPC エンドポイント ID を決定します。 ``` aws ec2 describe-vpc-endpoints ``` ``` { "VpcEndpoint": { "PolicyDocument": "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":\"*\",\"Action\":\"*\",\"Resource\":\"*\"}]}", "VpcId": "vpc-0bbc736e", "State": "available", "ServiceName": "com.amazonaws.us-east-1.dynamodb", "RouteTableIds": [], "VpcEndpointId": "vpce-9b15e2f2", "CreationTimestamp": "2017-07-26T22:00:14Z" } } ``` 出力例では、VPC エンドポイント ID は `vpce-9b15e2f2` です。 1. VPC エンドポイントを削除します。 ``` aws ec2 delete-vpc-endpoints --vpc-endpoint-ids vpce-9b15e2f2 ``` ``` { "Unsuccessful": [] } ``` 空の配列 `[]` は成功を示します (失敗したリクエストはありませんでした)。 **Amazon EC2 インスタンスを終了するには** 1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。 1. ナビゲーションペインで、[**インスタンス**] を選択します。 1. Amazon EC2 インスタンスを選択します。 1. [**Actions**]、[**Instance State**]、[**Terminate**] の順に選択します。 1. 確認ウィンドウで、**[Yes, Terminate]** (はい、終了します) を選択します。 # AWS PrivateLink for DynamoDB AWS PrivateLink for DynamoDB を使うと、仮想プライベートクラウド (Amazon VPC) でインターフェイス Amazon VPC エンドポイント** (インターフェイスエンドポイント) をプロビジョニングできます。これらのエンドポイントには、オンプレミスにあるアプリケーションから VPN および Direct Connect 経由で、または別の AWS リージョンにあるアプリケーションから [Amazon VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)経由で直接アクセスできます。AWS PrivateLink とインターフェイスエンドポイントを使用することで、アプリケーションから DynamoDB へのプライベートネットワーク接続を簡素化できます。 VPC 内のアプリケーションは、パブリック IP アドレスがなくても、DynamoDB VPC インターフェイスエンドポイントを使用して DynamoDB と通信し、DynamoDB の操作を実行できます。インターフェイスエンドポイントは、Amazon VPC 内のサブネットからプライベート IP アドレスが割り当てられた 1 つ以上の Elastic Network Interface (ENI) で表されます。インターフェイスエンドポイントを介した DynamoDB へのリクエストが Amazon ネットワーク外に出ることはありません。AWS Direct Connect または AWS Virtual Private Network (Site-to-Site VPN) を介して、オンプレミスのアプリケーションから Amazon VPC 内のインターフェイスエンドポイントにアクセスすることもできます。Amazon VPC をオンプレミスネットワークに接続する方法の詳細については、「[Direct Connect ユーザーガイド](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」および「[AWS Site-to-Site VPN ユーザーガイド](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」を参照してください。 インターフェイスエンドポイントの一般的な情報については、「*AWS PrivateLink ガイド*」の「[インターフェイス Amazon VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)」を参照してください。AWS PrivateLink は Amazon DynamoDB Streams エンドポイントでもサポートされています。詳細については、「[AWS PrivateLink for DynamoDB Streams](privatelink-streams.md)」を参照してください。 **Topics** + [Amazon DynamoDB で使用される Amazon VPC エンドポイントのタイプ](#types-of-vpc-endpoints-for-ddb) + [AWS PrivateLink for Amazon DynamoDB を使用する場合の考慮事項](#privatelink-considerations) + [Amazon VPC エンドポイントの作成](#ddb-creating-vpc) + [Amazon DynamoDB インターフェイスエンドポイントへのアクセス](#accessing-ddb-interface-endpoints) + [DynamoDB インターフェイスエンドポイントから DynamoDB テーブルおよびコントロール API オペレーションへのアクセス](#accessing-tables-apis-from-interface-endpoints) + [オンプレミスの DNS 設定の更新](#updating-on-premises-dns-config) + [DynamoDB 用 Amazon VPC エンドポイントポリシーの作成](#creating-vpc-endpoint-policy) + [AWS マネジメントコンソール プライベートアクセスでの DynamoDB エンドポイントの使用](#ddb-endpoints-private-access) + [AWS PrivateLink for DynamoDB Streams](privatelink-streams.md) + [DynamoDB Accelerator (DAX) での AWS PrivateLink の使用](dax-private-link.md) ## Amazon DynamoDB で使用される Amazon VPC エンドポイントのタイプ Amazon DynamoDB へのアクセスには、ゲートウェイエンドポイント**とインターフェイスエンドポイント** (AWS PrivateLink を使用) の 2 つのタイプの Amazon VPC エンドポイントを使用できます。ゲートウェイエンドポイント**は、AWS ネットワーク経由で Amazon VPC から DynamoDB にアクセスするために、ルートテーブルで指定するゲートウェイです。インターフェイスエンドポイント**は、プライベート IP アドレスを使用して、Amazon VPC 内、オンプレミス、または Amazon VPC ピアリングや AWS Transit Gateway を使用する別の AWS リージョンにある Amazon VPC から DynamoDB にリクエストをルーティングすることにより、ゲートウェイエンドポイントの機能を拡張します。詳細については、「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」および「[Transit Gateway と VPC ピアリング](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway-vs-vpc-peering.html)」を参照してください。 インターフェイスエンドポイントは、ゲートウェイエンドポイントと互換性があります。Amazon VPC 内に既存のゲートウェイエンドポイントがある場合は、同じ Amazon VPC で両方のタイプのエンドポイントを使用できます。 | DynamoDB のゲートウェイエンドポイント | DynamoDB のインターフェイスエンドポイント | | --- | --- | | いずれの場合も、ネットワークトラフィックは AWS ネットワーク上に残ります。 | | Amazon DynamoDB パブリック IP アドレスを使用する | Amazon VPC のプライベート IP アドレスを使用して Amazon DynamoDB にアクセスする | | オンプレミスからのアクセスを許可しない | オンプレミスからのアクセスを許可する | | 別の AWS リージョン からのアクセスを許可しない | Amazon VPC ピアリングまたは AWS Transit Gateway を使用する別の AWS リージョンにある Amazon VPC エンドポイントからのアクセスを許可する | | 課金されない | 請求される | ゲートウェイエンドポイントの詳細については、「AWS PrivateLink ガイド」**の「[Gateway Amazon VPC endpoints](https://docs.aws.amazon.com//vpc/latest/privatelink/vpce-gateway.html)」を参照してください。 ## AWS PrivateLink for Amazon DynamoDB を使用する場合の考慮事項 Amazon VPC に関する考慮事項が AWS PrivateLink for Amazon DynamoDB に適用されます。詳細については、*AWS PrivateLink ガイド*の「[インターフェイスエンドポイントの考慮事項](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations)」と「[AWS PrivateLink クォータ](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html)」を参照してください。また、以下の制約も適用されます。 AWS PrivateLink for Amazon DynamoDB では、以下はサポートされていません。 + Transport Layer Security (TLS) 1.1 + プライベートおよびハイブリッドドメインネームシステム (DNS) サービス **重要** DynamoDB エンドポイントの DNS 名 (`dynamodb.region.amazonaws.com` や `*.region.amazonaws.com` など) を上書きしてトラフィックをインターフェイスエンドポイントにルーティングするために、プライベートホストゾーンを作成しないでください。DynamoDB の DNS 設定は、時間の経過とともに変更される可能性があります。 カスタム DNS オーバーライドは、これらの変更と互換性がないため、リクエストがインターフェイスエンドポイントではなくパブリック IP アドレス経由で予期せずルーティングされる可能性があります。 AWS PrivateLink を介して DynamoDB にアクセスするには、Amazon VPC エンドポイント URL を直接使用するようにクライアントを設定します (例: `https://vpce-1a2b3c4d-5e6f.dynamodb.region.vpce.amazonaws.com`)。 有効にする AWS PrivateLink エンドポイントごとに、1 秒あたり最大 5 万件のリクエストを送信できます。 **注記** AWS PrivateLink エンドポイントへのネットワーク接続タイムアウトは DynamoDB エラーレスポンスの範囲ではないため、PrivateLink エンドポイントに接続するアプリケーションで適切に処理する必要があります。 ## Amazon VPC エンドポイントの作成 Amazon VPC インターフェイスエンドポイントを作成するには、「AWS PrivateLink ガイド」**の「[Create an Amazon VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。 ## Amazon DynamoDB インターフェイスエンドポイントへのアクセス インターフェイスエンドポイントを作成すると、DynamoDB はエンドポイント固有の 2 つのタイプの DynamoDB DNS 名 (*Regional* および *Zonal*) を生成します。 + Regional** DNS 名では、一意の Amazon VPC エンドポイント ID、サービス識別子、AWS リージョン、および `vpce.amazonaws.com` が名前に含まれます。例えば、Amazon VPC エンドポイント ID が `vpce-1a2b3c4d` の場合、生成される DNS 名は `vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com` のようになります。 + *Zonal* DNS 名には、アベイラビリティーゾーンが含まれます (`vpce-1a2b3c4d-5e6f-us-east-1a.dynamodb.us-east-1.vpce.amazonaws.com` など)。このオプションは、アーキテクチャがアベイラビリティーゾーンを分離する場合に使用できます。例えば、障害を隔離し、リージョン間のデータ転送コストを削減するために使用できます。 **注記** 最適な信頼性を実現するには、最低 3 つのアベイラビリティーゾーンにサービスをデプロイすることをお勧めします。 ## DynamoDB インターフェイスエンドポイントから DynamoDB テーブルおよびコントロール API オペレーションへのアクセス DynamoDB インターフェイスエンドポイントを介して DynamoDB テーブルおよびコントロール API オペレーションにアクセスするには、AWS CLI または AWS SDK を使用します。 ### AWS CLI の例 AWS CLI コマンドを使って DynamoDB インターフェイスエンドポイントを介して DynamoDB テーブルまたは DynamoDB コントロール API オペレーションにアクセスするには、`--region` および `--endpoint-url` パラメータを使用します。 **例: VPC エンドポイントの作成** ``` aws ec2 create-vpc-endpoint \ --region us-east-1 \ --service-name com.amazonaws.us-east-1.dynamodb \ --vpc-id client-vpc-id \ --subnet-ids client-subnet-id \ --vpc-endpoint-type Interface \ --security-group-ids client-sg-id ``` **例: VPC エンドポイントの変更** ``` aws ec2 modify-vpc-endpoint \ --region us-east-1 \ --vpc-endpoint-id client-vpc-endpoint-id \ --policy-document policy-document \ #example optional parameter --add-security-group-ids security-group-ids \ #example optional parameter # any additional parameters needed, see Privatelink documentation for more details ``` **例: エンドポイント URL を使ったテーブルの一覧表示** 次の例では、リージョン `us-east-1`、VPC エンドポイント ID の DNS 名 `vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` aws dynamodb --region us-east-1 --endpoint https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com list-tables ``` ### AWS SDK の例 AWS SDK を使って DynamoDB インターフェイスエンドポイントを介して DynamoDB テーブルまたは DynamoDB コントロール API オペレーションにアクセスするには、SDK を最新バージョンに更新します。次に、エンドポイント URL を使用して DynamoDB インターフェイスエンドポイントを介してテーブルまたは DynamoDB コントロール API オペレーションにアクセスするように、クライアントを設定します。 ------ #### [ SDK for Python (Boto3) ] **例: エンドポイント URL を使用して DynamoDB テーブルにアクセスする** 次の例では、リージョン `us-east-1` および VPC エンドポイント ID `https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` ddb_client = session.client( service_name='dynamodb', region_name='us-east-1', endpoint_url='https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com' ) ``` ------ #### [ SDK for Java 1.x ] **例: エンドポイント URL を使用して DynamoDB テーブルにアクセスする** 次の例では、リージョン `us-east-1` および VPC エンドポイント ID `https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` //client build with endpoint config final AmazonDynamoDB dynamodb = AmazonDynamoDBClientBuilder.standard().withEndpointConfiguration( new AwsClientBuilder.EndpointConfiguration( "https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com", Regions.DEFAULT_REGION.getName() ) ).build(); ``` ------ #### [ SDK for Java 2.x ] **例: エンドポイント URL を使用して DynamoDB テーブルにアクセスする** 次の例では、リージョン us-east-1 と VPC エンドポイント ID https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com をユーザー自身の情報に置き換えます。 ``` Region region = Region.US_EAST_1; dynamoDbClient = DynamoDbClient.builder().region(region) .endpointOverride(URI.create("https://vpce-1a2b3c4d-5e6f.dynamodb.us-east-1.vpce.amazonaws.com")) .build() ``` ------ ## オンプレミスの DNS 設定の更新 エンドポイント固有の DNS 名を使用して DynamoDB のインターフェイスエンドポイントにアクセスする場合、オンプレミス DNS リゾルバーを更新する必要はありません。パブリック DynamoDB DNS ドメインから、インターフェイスエンドポイントのプライベート IP アドレスを使用してエンドポイント固有の DNS 名を解決できます。 ### Amazon VPC 内のゲートウェイエンドポイントまたはインターネットゲートウェイは使用せず、インターフェイスエンドポイントを使用して DynamoDB にアクセスする 次の図に示すように、Amazon VPC 内のインターフェイスエンドポイントは、Amazon VPC 内のアプリケーションとオンプレミスアプリケーションの両方を Amazon ネットワーク経由で DynamoDB にルーティングできます。 ![\[インターフェイスエンドポイントと AWS PrivateLink を使用した、オンプレミスアプリケーションと Amazon VPC 内のアプリケーションから DynamoDB へのアクセスを示すデータフロー図。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/PrivateLink-interfaceEndpoints.png) この図表は、以下を示すものです: + オンプレミスネットワークでは、Direct Connect または Site-to-Site VPN を使用して Amazon VPC A に接続します。 + オンプレミスと Amazon VPC A 内のアプリケーションでは、エンドポイント固有の DNS 名を使用して DynamoDB インターフェイスエンドポイントを介して DynamoDB にアクセスします。 + オンプレミスのアプリケーションは、Direct Connect (または Site-to-Site VPN) を介して Amazon VPC 内のインターフェイスエンドポイントにデータを送信します。AWS PrivateLink は、AWS ネットワークを経由してデータをインターフェイスエンドポイントから DynamoDB に移動します。 + Amazon VPC 内のアプリケーションも、インターフェイスエンドポイントにトラフィックを送信します。AWS PrivateLink は、AWS ネットワークを経由してデータをインターフェイスエンドポイントから DynamoDB に移動します。 ### ゲートウェイエンドポイントとインターフェイスエンドポイントを同じ Amazon VPC で併用して DynamoDB にアクセスする 次の図に示すように、インターフェイスエンドポイントを作成し、同じ Amazon VPC 内に既存のゲートウェイエンドポイントも保持できます。このアプローチにより、Amazon VPC 内のアプリケーションが引き続きゲートウェイエンドポイントを介して DynamoDB にアクセスすることが許可されます。これについての請求はありません。インターフェイスエンドポイントは、DynamoDB にアクセスするオンプレミスのアプリケーションだけが使用することになります。この方法で DynamoDB にアクセスするには、DynamoDB のエンドポイント固有の DNS 名を使用するようにオンプレミスのアプリケーションを更新する必要があります。 ![\[ゲートウェイエンドポイントとインターフェイスエンドポイントを併用した DynamoDB へのアクセスを示すデータフロー図。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/PL-Image2-InterfaceAndGatewayEP.png) この図表は、以下を示すものです: + オンプレミスのアプリケーションは、エンドポイント固有の DNS 名を使用して、Direct Connect (または Site-to-Site VPN) を介して Amazon VPC 内のインターフェイスエンドポイントにデータを送信します。AWS PrivateLink は、AWS ネットワークを経由してデータをインターフェイスエンドポイントから DynamoDB に移動します。 + Amazon VPC 内のアプリケーションは、デフォルトのリージョン DynamoDB 名を使用し、AWS ネットワークを経由して DynamoDB に接続するゲートウェイエンドポイントにデータを送信します。 ゲートウェイエンドポイントの詳細については、「Amazon VPC ユーザーガイド」**の「[Gateway Amazon VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html)」を参照してください。 ## DynamoDB 用 Amazon VPC エンドポイントポリシーの作成 Amazon VPC エンドポイントに DynamoDB へのアクセスをコントロールするエンドポイントポリシーをアタッチできます。このポリシーでは、以下の情報を指定します。 + アクションを実行できる AWS Identity and Access Management (IAM) プリンシパル + 実行可能なアクション + アクションを実行できるリソース **Topics** + [例: Amazon VPC エンドポイントから特定のテーブルへのアクセスの制限](#privatelink-example-restrict-access-to-bucket) ### 例: Amazon VPC エンドポイントから特定のテーブルへのアクセスの制限 特定の DynamoDB テーブルへのアクセスのみを制限するエンドポイントポリシーを作成できます。このタイプのポリシーは、テーブルを使用する他の AWS のサービスが Amazon VPC にある場合に便利です。次のテーブルポリシーは、`DOC-EXAMPLE-TABLE` へのアクセスのみを制限します。このエンドポイントポリシーを使用するには、`DOC-EXAMPLE-TABLE` をテーブルの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Policy1216114807515", "Statement": [ { "Sid": "Access-to-specific-table-only", "Principal": "*", "Action": [ "dynamodb:GetItem", "dynamodb:PutItem" ], "Effect": "Allow", "Resource": ["arn:aws:dynamodb:us-east-1:111122223333:table/DOC-EXAMPLE-TABLE", "arn:aws:dynamodb:us-east-1:111122223333:table/DOC-EXAMPLE-TABLE/*"] } ] } ``` ------ ## AWS マネジメントコンソール プライベートアクセスでの DynamoDB エンドポイントの使用 [AWS マネジメントコンソール プライベートアクセス](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html)の [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb)で VPC エンドポイントを使用する場合は、DynamoDB と DynamoDB Streams の DNS 設定を設定する必要があります。 AWS マネジメントコンソール プライベートアクセスでアクセスできるように DynamoDB を設定するには、次の 2 つの VPC エンドポイントを作成する必要があります。 + `com.amazonaws..dynamodb` + `com.amazonaws..dynamodb-streams` VPC エンドポイントを作成する場合、Route53 コンソールに移動し、リージョンエンドポイント `dynamodb.us-east-1.amazonaws.com` を使用して DynamoDB のプライベートホストゾーンを作成します。 プライベートホストゾーンに次の 2 つのエイリアスレコードを作成します。 + トラフィックを VPC エンドポイント `com.amazonaws..dynamodb` にルーティングする `dynamodb..amazonaws.com`。 + トラフィックを VPC エンドポイント `com.amazonaws..dynamodb-streams` にルーティングする `streams.dynamodb..amazonaws.com`。 # AWS PrivateLink for DynamoDB Streams AWS PrivateLink for Amazon DynamoDB Streams を使用すると、仮想プライベートクラウド (Amazon VPC) でインターフェイス Amazon VPC エンドポイント (インターフェイスエンドポイント) をプロビジョニングできます。これらのエンドポイントには、オンプレミスにあるアプリケーションから VPN および Direct Connect 経由で、または別の AWS リージョン にあるアプリケーションから Amazon VPC ピアリング経由で直接アクセスできます。AWS PrivateLink とインターフェイスエンドポイントを使用することで、アプリケーションから DynamoDB Streams へのプライベートネットワーク接続を簡素化できます。 Amazon VPC 内のアプリケーションは、パブリック IP アドレスがなくても、Amazon VPC インターフェイスエンドポイントを使用して DynamoDB Streams と通信し、DynamoDB Streams の操作を実行できます。インターフェイスエンドポイントは、Amazon VPC 内のサブネットからプライベート IP アドレスが割り当てられた 1 つ以上の Elastic Network Interface (ENI) で表されます。インターフェイスエンドポイントを介した DynamoDB Streams へのリクエストが Amazon ネットワーク外に出ることはありません。Direct Connect または AWS Virtual Private Network (AWS VPN) を介して、オンプレミスのアプリケーションから Amazon VPC 内のインターフェイスエンドポイントにアクセスすることもできます。AWS Virtual Private Network をオンプレミスネットワークに接続する方法の詳細については、「[https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」および「[https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」を参照してください。 インターフェイスエンドポイントの一般的な情報については、「[Interface Amazon VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink)」を参照してください。 **注記** DynamoDB Streams では、インターフェイスエンドポイントのみがサポートされています。ゲートウェイエンドポイントはサポートされていません。 **Topics** + [AWS PrivateLink for Amazon DynamoDB Streams を使用する場合の考慮事項](#privatelink-streams-considerations) + [Amazon VPC エンドポイントの作成](#privatelink-streams-vpc-endpoint) + [Amazon DynamoDB Streams インターフェイスエンドポイントへのアクセス](#privatelink-streams-accessing-ddb-interface-endpoints) + [DynamoDB Streams インターフェイスエンドポイントから DynamoDB Streams API オペレーションへのアクセス](#privatelink-streams-accessing-api-operations-from-interface-endpoints) + [AWS SDK の例](#privatelink-streams-aws-sdk-examples) + [DynamoDB Streams 用 Amazon VPC エンドポイントポリシーの作成](#privatelink-streams-creating-vpc-endpoint-policy) + [AWS マネジメントコンソール プライベートアクセスでの DynamoDB エンドポイントの使用](#ddb-streams-endpoints-private-access) ## AWS PrivateLink for Amazon DynamoDB Streams を使用する場合の考慮事項 Amazon VPC に関する考慮事項が AWS PrivateLink for Amazon DynamoDB Streams に適用されます。詳細については、「[interface endpoint considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」および「[AWS PrivateLink quotas](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html)」を参照してください。以下の制限が適用されます。 AWS PrivateLink for Amazon DynamoDB Streams では、以下はサポートされていません。 + Transport Layer Security (TLS) 1.1 + プライベートおよびハイブリッドドメインネームシステム (DNS) サービス **重要** DynamoDB Streams エンドポイントの DNS 名を上書きして、トラフィックをインターフェイスエンドポイントにルーティングするために、プライベートホストゾーンを作成しないでください。DynamoDB の DNS 設定は時間の経過とともに変更される可能性があり、カスタム DNS オーバーライドにより、リクエストがインターフェイスエンドポイントではなくパブリック IP アドレス経由で予期せずルーティングされる可能性があります。 AWS PrivateLink を介して DynamoDB Streams にアクセスするには、Amazon VPC エンドポイント URL を直接使用するようにクライアントを設定します (例: `https://vpce-1a2b3c4d-5e6f.streams.dynamodb.region.vpce.amazonaws.com`)。 **注記** AWS PrivateLink エンドポイントへのネットワーク接続タイムアウトは DynamoDB Streams エラーレスポンスの範囲ではないため、AWS PrivateLink エンドポイントに接続するアプリケーションで適切に処理する必要があります。 ## Amazon VPC エンドポイントの作成 Amazon VPC インターフェイスエンドポイントを作成するには、「AWS PrivateLink ガイド」**の「[Create an Amazon VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。 ## Amazon DynamoDB Streams インターフェイスエンドポイントへのアクセス インターフェイスエンドポイントを作成すると、DynamoDB はエンドポイント固有の 2 つのタイプの DynamoDB Streams DNS 名 (*Regional* および *Zonal*) を生成します。 + Regional** DNS 名では、一意の Amazon VPC エンドポイント ID、サービス識別子、AWS リージョン、および `vpce.amazonaws.com` が名前に含まれます。例えば、Amazon VPC エンドポイント ID が `vpce-1a2b3c4d` の場合、生成される DNS 名は `vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com` のようになります。 + *Zonal* DNS 名には、アベイラビリティーゾーンが含まれます (`vpce-1a2b3c4d-5e6f-us-east-1a.streams.dynamodb.us-east-1.vpce.amazonaws.com` など)。このオプションは、アーキテクチャがアベイラビリティーゾーンを分離する場合に使用できます。例えば、障害を隔離し、リージョン間のデータ転送コストを削減するために使用できます。 ## DynamoDB Streams インターフェイスエンドポイントから DynamoDB Streams API オペレーションへのアクセス DynamoDB Streams インターフェイスエンドポイントを介して DynamoDB Streams API オペレーションにアクセスするには、AWS CLI SDK または AWS SDK を使用します。 ### AWS CLI の例 AWS CLI コマンドで DynamoDB Streams インターフェイスエンドポイントを介して DynamoDB Streams または API オペレーションにアクセスするには、`--region` パラメータおよび `--endpoint-url` パラメータを使用します。 **例: VPC エンドポイントの作成** ``` aws ec2 create-vpc-endpoint \ --region us-east-1 \ --service-name com.amazonaws.us-east-1.dynamodb-streams \ --vpc-id client-vpc-id \ --subnet-ids client-subnet-id \ --vpc-endpoint-type Interface \ --security-group-ids client-sg-id ``` **例: VPC エンドポイントの変更** ``` aws ec2 modify-vpc-endpoint \ --region us-east-1 \ --vpc-endpoint-id client-vpc-endpoint-id \ --policy-document policy-document \ #example optional parameter --add-security-group-ids security-group-ids \ #example optional parameter # any additional parameters needed, see Privatelink documentation for more details ``` **例: エンドポイント URL を使ったストリームの一覧表示** 次の例では、リージョン `us-east-1`、VPC エンドポイント ID の DNS 名 `vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` aws dynamodbstreams --region us-east-1 —endpoint https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com list-streams ``` ## AWS SDK の例 AWS SDK を使って DynamoDB Streams インターフェイスエンドポイントを介して Amazon DynamoDB Streams API オペレーションにアクセスするには、SDK を最新バージョンに更新します。次に、エンドポイント URL を使用して DynamoDB Streams インターフェイスエンドポイントを介して DynamoDB Streams API オペレーションにアクセスするように、クライアントを設定します。 ------ #### [ SDK for Python (Boto3) ] **例: エンドポイント URL を使用して DynamoDB stream にアクセスする** 次の例では、リージョン `us-east-1` および VPC エンドポイント ID `https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` ddb_streams_client = session.client( service_name='dynamodbstreams', region_name='us-east-1', endpoint_url='https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com' ) ``` ------ #### [ SDK for Java 1.x ] **例: エンドポイント URL を使用して DynamoDB stream にアクセスする** 次の例では、リージョン `us-east-1` および VPC エンドポイント ID `https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` //client build with endpoint config final AmazonDynamoDBStreams dynamodbstreams = AmazonDynamoDBStreamsClientBuilder.standard().withEndpointConfiguration( new AwsClientBuilder.EndpointConfiguration( "https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com", Regions.DEFAULT_REGION.getName() ) ).build(); ``` ------ #### [ SDK for Java 2.x ] **例: エンドポイント URL を使用して DynamoDB stream にアクセスする** 次の例では、リージョン `us-east-1` および VPC エンドポイント ID `https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com` をユーザー自身の情報に置き換えます。 ``` Region region = Region.US_EAST_1; dynamoDbStreamsClient = DynamoDbStreamsClient.builder().region(region) .endpointOverride(URI.create("https://vpce-1a2b3c4d-5e6f.streams.dynamodb.us-east-1.vpce.amazonaws.com")) .build() ``` ------ ## DynamoDB Streams 用 Amazon VPC エンドポイントポリシーの作成 Amazon VPC エンドポイントに DynamoDB Streams へのアクセスをコントロールするエンドポイントポリシーをアタッチできます。このポリシーでは、以下の情報を指定します。 + アクションを実行できる AWS Identity and Access Management (IAM) プリンシパル + 実行可能なアクション + アクションを実行できるリソース **Topics** + [例: Amazon VPC エンドポイントから特定のストリームへのアクセスの制限](#privatelink-streams-example-restrict-access-to-bucket) ### 例: Amazon VPC エンドポイントから特定のストリームへのアクセスの制限 特定の DynamoDB Streams へのアクセスのみを制限するエンドポイントポリシーを作成できます。このタイプのポリシーは、DynamoDB Streams を使用する他の AWS のサービス が Amazon VPC にある場合に便利です。次のストリームポリシーは、`DOC-EXAMPLE-TABLE` にアタッチされた `2025-02-20T11:22:33.444` ストリームのみへのアクセスを制限します。このエンドポイントポリシーを使用するには、`DOC-EXAMPLE-TABLE` をテーブルの名前で、`2025-02-20T11:22:33.444` をストリームラベルで、それぞれ置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Policy1216114807515", "Statement": [ { "Sid": "Access-to-specific-stream-only", "Principal": "*", "Action": [ "dynamodb:DescribeStream", "dynamodb:GetRecords" ], "Effect": "Allow", "Resource": ["arn:aws:dynamodb:us-east-1:111122223333:table/table-name/stream/2025-02-20T11:22:33.444"] } ] } ``` ------ **注記** ゲートウェイエンドポイントは DynamoDB Streams ではサポートされていません。 ## AWS マネジメントコンソール プライベートアクセスでの DynamoDB エンドポイントの使用 [AWS マネジメントコンソール プライベートアクセス](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html)の [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb)で VPC エンドポイントを使用する場合は、DynamoDB と DynamoDB Streams の DNS 設定を設定する必要があります。 AWS マネジメントコンソール プライベートアクセスでアクセスできるように DynamoDB を設定するには、次の 2 つの VPC エンドポイントを作成する必要があります。 + `com.amazonaws..dynamodb` + `com.amazonaws..dynamodb-streams` VPC エンドポイントを作成する場合、Route53 コンソールに移動し、リージョンエンドポイント `dynamodb.us-east-1.amazonaws.com` を使用して DynamoDB のプライベートホストゾーンを作成します。 プライベートホストゾーンに次の 2 つのエイリアスレコードを作成します。 + トラフィックを VPC エンドポイント `com.amazonaws..dynamodb` にルーティングする `dynamodb..amazonaws.com`。 + トラフィックを VPC エンドポイント `com.amazonaws..dynamodb-streams` にルーティングする `streams.dynamodb..amazonaws.com`。 # DynamoDB Accelerator (DAX) での AWS PrivateLink の使用 DynamoDB Accelerator (DAX) 用 AWS PrivateLink を使用すると、仮想プライベートクラウド (VPC) 内のプライベート IP アドレスを介して、`CreateCluster`、`DescribeClusters`、`DeleteCluster` などの DAX 管理 API に安全にアクセスできます。この機能を使用すると、パブリックインターネットにトラフィックを公開することなく、アプリケーションから DAX サービスにプライベートにアクセスできます。 DAX PrivateLink はデュアルスタックエンドポイント (`dax.{region}.api.aws`) をサポートし、IPv4 と IPv6 の両方の接続を可能にします。DAX 用 AWS PrivateLink を使用すると、お客様はプライベート DNS 名を使用してサービスにアクセスできます。デュアルスタックのエンドポイントサポートにより、ネットワークのプライバシーを維持しながら透過的な接続が確保されます。これにより、SDK 設定を変更することなく、パブリックインターネットと VPC エンドポイントの両方から DAX にアクセスできます。 ## DynamoDB Accelerator (DAX) 用 AWS PrivateLink を使用する際の考慮事項 DynamoDB Accelerator (DAX) 用 AWS PrivateLink を実装するときは、いくつかの重要な考慮事項を考慮する必要があります。 DAX のインターフェイスエンドポイントを設定する前に、次の点を考慮してください。 + DAX インターフェイスエンドポイントは、同じ AWS リージョン内の DAX 管理 API へのアクセスのみをサポートします。インターフェイスエンドポイントを使用して、他のリージョンの DAX 管理 API にアクセスすることはできません。 + DAX 管理のためにAWS マネジメントコンソールにプライベートにアクセスするには、`com.amazonaws.region.console` や関連サービスなどのサービス用の追加の VPC エンドポイントを作成する必要がある場合があります。 + DAX へのインターフェイスエンドポイントの作成と使用には料金がかかります。料金情報については、「[AWS PrivateLink の料金](https://aws.amazon.com/vpc/pricing/)」を参照してください。 ## AWS PrivateLink と DAX の連携方法 DAX のインターフェイスエンドポイントを作成する場合。 1. AWS は、インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。 1. これらは、DAX 宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。 1. その後、VPC 内のプライベート IP アドレスを介して DAX にアクセスできます。 1. このアーキテクチャでは、VPC セキュリティグループを使用してエンドポイントへのアクセスを管理できます。 1. アプリケーションは、VPC 内の各インターフェイスエンドポイントを介して DynamoDB と DAX の両方にアクセスできますが、オンプレミスアプリケーションは Direct Connect または VPN 経由で接続することもできます。 1. これにより、両方のサービス間で一貫した接続モデルが提供され、アーキテクチャが簡素化され、トラフィックを AWS ネットワーク内に維持することでセキュリティが向上します。 ## DAX のインターフェイスエンドポイントの作成 インターフェイスエンドポイントを作成して、AWS マネジメントコンソール、AWS SDK、CloudFormation、または AWS API を使用して DAX に接続できます。 **コンソールを使用して DAX のインターフェイスエンドポイントを作成するには** 1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) で Amazon VPC コンソールに移動します。 1. ナビゲーションペインで、**[エンドポイント]** を選択します。 1. [**エンドポイントの作成**] を選択します。 1. **[サービスカテゴリ]** で **[AWS のサービス]**を選択し、**[サービス名]** で `com.amazonaws.region.dax` を検索して選択します。 1. **VPC** の場合は、DAX にアクセスする VPC を選択し、**サブネット**の場合は、AWS がエンドポイントネットワークインターフェイスを作成するサブネットを選択します。 1. **[セキュリティグループ]** で、エンドポイントネットワークインターフェイスに関連付けるセキュリティグループを選択します。 1. **[ポリシー]** で、デフォルトの **[フルアクセス]** を維持するか、必要に応じてカスタマイズします。 1. **[DNS 名を有効化]** を選択して、エンドポイントのプライベート DNS を有効化します。SDK 設定の変更を防ぐために、プライベート DNS 名を有効にしておきます。有効にすると、アプリケーションは標準サービスの DNS 名 (例: `dax.region.amazonaws.com`) を引き続き使用できます。AWS は、この名前をエンドポイントのプライベート IP アドレスに解決するプライベートホストゾーンを VPC 内に作成します。 **注記** 必要に応じてリージョン DNS 名を使用します。ゾーン DNS 名の使用はお勧めしません。また、3 つ以上の AZ からサブネットを選択し、PrivateLink を介して最大可用性を確保します。 1. **エンドポイントの作成** を選択します。 **AWS CLI を使用して DAX のインターフェイスエンドポイントを作成するには** `vpc-endpoint-type` パラメータを `Interface` に設定し、`service-name` パラメータを `com.amazonaws.region.dax` に設定して、`create-vpc-endpoint` コマンドを使用します。 ``` aws ec2 create-vpc-endpoint \ --vpc-id vpc-ec43eb89 \ --vpc-endpoint-type Interface \ --service-name com.amazonaws.us-east-1.dax \ --subnet-ids subnet-abcd1234 subnet-1a2b3c4d \ --security-group-ids sg-1a2b3c4d \ --private-dns-enabled ``` ## その他のリソース AWS PrivateLink と VPC エンドポイントの使用の詳細については、以下のリソースを参照してください。 + [AWS PrivateLink for DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/privatelink-interface-endpoints.html) + [AWS PrivateLink for DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/privatelink-streams.html) + [ を使用して VPC をサービスに接続するAWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) + [ を使用して DynamoDB へのプライベート接続を簡素化するAWS PrivateLink](https://aws.amazon.com/blogs//database/simplify-private-connectivity-to-amazon-dynamodb-with-aws-privatelink) + [AWS PrivateLink ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-privatelink.html) # Amazon DynamoDB での設定と脆弱性の分析 AWS は、ゲストオペレーティングシステム (OS) やデータベースへのパッチ適用、ファイアウォール設定、ディザスターリカバリーなどの基本的なセキュリティタスクを処理します。これらの手順は適切な第三者によって確認され、証明されています。詳細については、以下のリソースを参照してください。 + [Amazon DynamoDB のコンプライアンス検証](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Compliance.html) + [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/) + [アマゾン ウェブ サービス: セキュリティプロセスの概要](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) (ホワイトペーパー) 以下のセキュリティのベストプラクティスも Amazon DynamoDB での設定と脆弱性の分析に対処します。 + [ を使用した DynamoDB コンプライアンスのモニタリングAWS Config ルール](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices-security-detective.html#rules) + [ を使用した DynamoDB 設定のモニタリングAWS Config](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices-security-detective.html#config) # Amazon DynamoDB のセキュリティベストプラクティス Amazon DynamoDB には、独自のセキュリティポリシーを策定および実装する際に考慮すべきさまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションに相当するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは処方箋ではなく、有用な考慮事項と考えてください。 **Topics** + [DynamoDB での予防的セキュリティのベストプラクティス](best-practices-security-preventative.md) + [DynamoDB Detective によるセキュリティのベストプラクティス](best-practices-security-detective.md) # DynamoDB での予防的セキュリティのベストプラクティス 以下のベストプラクティスは、Amazon DynamoDB のセキュリティインシデントの予防に役立ちます。 **保管時の暗号化** DynamoDB は、[AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) に保存されているテーブル、インデックス、ストリーミング、Backup に保存されているすべてのユーザーデータを保存時に暗号化します。この機能は、基になるストレージへの不正アクセスからデータを保護することによって、データ保護の追加レイヤーを提供します。 DynamoDB でユーザーデータを暗号化するために AWS 所有のキー (デフォルトの暗号化タイプ)、AWS マネージドキー を使用するか、カスタマーマネージドキーを使用するかを指定できます。詳細については、「[保管時の Amazon DynamoDB 暗号化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)」を参照してください。 **IAM ロールを使用した DynamoDB へのアクセス認証** ユーザー、アプリケーション、およびその他の AWS サービスが DynamoDB にアクセスするには、有効な AWS 認証情報が AWS API リクエストに含まれている必要があります。アプリケーションまたは EC2 インスタンスに AWS 認証情報を直接保存しないでください。自動更新されない長期認証情報条件のため、漏洩すると業務に深刻な悪影響が及ぶ可能性があります。IAM ロールでは、AWS サービスおよびリソースにアクセスするために使用できる一時的なアクセスキーを有効にすることができます。 詳細については、「[Amazon DynamoDB の Identity and Access Management](security-iam.md)」を参照してください。 **IAM ポリシーを使用した DynamoDB ベース認可** 許可を付与する場合、許可を取得するユーザー、取得する許可の対象となる DynamoDB API、およびそれらのリソースに対して許可される特定のアクションを決定します。最小限の特権の実装は、セキュリティリスクはもちろん、エラーや悪意ある行動によってもたらされる可能性のある影響を減らす上での鍵となります。 IAM アイデンティティ (ユーザー、グループ、ロール) にアクセス権限ポリシーをアタッチし、DynamoDB リソースでオペレーションを実行する許可を付与します。 これを行うには、次を使用します。 + [AWS 管理 (事前定義) ポリシー](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/using-identity-based-policies.html#access-policy-examples-aws-managed) + [カスタマー管理ポリシー](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/using-identity-based-policies.html#access-policy-examples-for-sdk-cli) **詳細に設定されたアクセスコントロールのための IAM ポリシー条件を使用する** DynamoDB でアクセス権限を付与するときは、アクセス権限ポリシーを有効にする方法を決める条件を指定できます。最小限の特権の実装は、セキュリティリスクはもちろん、エラーや悪意ある行動によってもたらされる可能性のある影響を減らす上での鍵となります。 IAM ポリシーを使用して、アクセス許可を付与するときに条件を指定できます。例えば、次の操作を実行できます。 + テーブルまたはセカンダリインデックス内の項目と属性に対する読み込み専用アクセスをユーザーに許可する許可を付与します。 + ユーザーのアイデンティティに基づいて、テーブルの特定の属性への書き込み専用アクセスのアクセス権限をユーザーに付与します。 詳細については、「[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html)」を参照してください。 **VPC エンドポイントとポリシーを使用した DynamoDB へのアクセス** Virtual Private Cloud (VPC) 内からのみ DynamoDB にアクセスする必要がある場合は、VPC エンドポイントを使用して、必要な VPC からのみのアクセスに制限する必要があります。これにより、トラフィックがオープンインターネットを通過してその環境に晒されるのを防ぐことができます。 DynamoDB の VPC エンドポイントを使用すると、以下を使用してアクセスを制御および制限できます。 + VPC エンドポイントポリシー — これらのポリシーは DynamoDB VPC エンドポイントに適用されます。DynamoDB テーブルへの API アクセスを制御および制限が許可されます。 + IAM ポリシー — ユーザー、グループ、またはロールにアタッチされたポリシーで `aws:sourceVpce` 条件を使用すると、DynamoDB テーブルへのすべてのアクセスが指定の VPC エンドポイントを経由するよう強制できます。 詳細については、「[Amazon DynamoDB のエンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-ddb.html)」を参照してください。 **クライアント側の暗号化を考慮する** DynamoDB にテーブルを実装する前に、暗号化戦略を計画することをお勧めします。機密データまたは機密データを DynamoDB に保存する場合は、クライアント側の暗号化をプランに含めることを検討してください。これにより、データをできるだけ送信元に近い状態で暗号化し、ライフサイクル全体にわたってデータを確実に保護できます。伝送中および保管時の機密データを暗号化することで、サードパーティーがお客様のプレーンテキストデータを使用することはできません。 [DynamoDB 用の AWS Database Encryption SDK](https://docs.aws.amazon.com/dynamodb-encryption-client/latest/devguide/what-is-ddb-encrypt.html) は、DynamoDB に送信する前にテーブルデータを保護するのに役立つソフトウェアライブラリです。DynamoDB テーブル項目を暗号化、署名、検証、復号します。どの属性を暗号化して署名するかを制御できます。 **プライマリキーに関する考慮事項** テーブルやグローバルセカンダリインデックスでは、[プライマリキー](HowItWorks.Partitions.md)に機密性の高い名前やプレーンテキストデータを使用しないでください。キー名はテーブル定義に表示されます。例えば、プライマリキー名は、[DescribeTable](WorkingWithTables.Basics.md#WorkingWithTables.Basics.DescribeTable) を呼び出すアクセス許可を持つすべてのユーザーがアクセスできます。キー値は、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) やその他のログに表示される場合があります。さらに、DynamoDB はデータの配信とリクエストのルーティングにキー値を使用します。AWS 管理者は、この値を観察してサービスのヘルスを維持する場合があります。 テーブルや GSI のキー値に機密データを使用する必要がある場合は、エンドツーエンドのクライアント暗号化を使用することをお勧めします。これにより、データへのキー値の参照を実行する際に、データが暗号化されないまま DynamoDB 関連ログに表示されることを回避できます。これを実現する 1 つの方法は、[AWS Database Encryption SDK for DynamoDB](https://docs.aws.amazon.com/database-encryption-sdk/latest/devguide/client-server-side.html) を使用することですが、これは必須ではありません。独自のソリューションを使用する場合は、十分に安全な暗号化アルゴリズムを常に使用する必要があります。ハッシュなどの非暗号化オプションは、ほとんどの状況で十分に安全とは見なされないため、使用しないでください。 プライマリキーの名前が機密である場合は、代わりに ``pk`` と ``sk`` を使用することをお勧めします。これは、パーティションキーの設計を柔軟に保つ一般的なベストプラクティスです。 どれが適切な選択肢であるか不安な場合は、必ずセキュリティエキスパートまたは AWS アカウントチームに相談してください。 # DynamoDB Detective によるセキュリティのベストプラクティス 以下は、潜在的なセキュリティ上の弱点とインシデントを検出するために役立つ Amazon DynamoDB でのベストプラクティスです。 **AWS CloudTrail を使用した AWS マネージド KMS キーの使用状況モニタリング** 保管時の暗号化に [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) を使用している場合、このキーの使用状況が AWS CloudTrail に記録されます。CloudTrail は、アカウントで実行されたアクションをレコードすることで、ユーザーのアクティビティを可視化します。CloudTrail は、リクエストを行ったユーザー、使用されたサービス、実行されたアクション、アクションのパラメータ、AWS のサービスから返されたレスポンス要素など、各アクションに関する重要な情報をレコードします。この情報は、AWS リソースに加えられた変更を追跡し、オペレーション上の問題をトラブルシューティングするサポートになります。CloudTrail を使用すると、社内ポリシーや規制スタンダードへのコンプライアンスが容易になります。 CloudTrail を使用して、キーの使用状況を監査できます。CloudTrail は、アカウントの AWS API コールおよび関連イベントの履歴を含むログファイルを作成します。これらのログファイルには、統合された AWS サービスを通じて行われたものに加えて、AWS マネジメントコンソール、AWS SDK、およびコマンドラインツールを使用して行われたすべての AWS KMS API リクエストが含まれます。これらのログファイルを使って、KMS が使用された日時、リクエストされたオペレーション、リクエスタの ID、リクエスト元の IP アドレスなどについての情報を取得できます。詳細については、「[AWS CloudTrail を使用した AWS KMS API 呼び出しのログ記録](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html)」と「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。 **CloudTrail を使用した DynamoDB オペレーションのモニタリング** CloudTrail は、コントロールプレーンイベントとデータプレーンイベントの両方をモニタリングできます。コントロールプレーンのオペレーションでは、DynamoDB テーブルを作成および管理できます。また、インデックス、ストリーム、およびテーブルに依存する他のオブジェクトを操作できます。データプレーンオペレーションでは、テーブルのデータで、作成、読み込み、更新、および削除 (*CRUD* とも呼ばれる) アクションを実行できます。一部のデータプレーンオペレーションでも、セカンダリインデックスからデータを読み込むことができます。CloudTrail でデータプレーンイベントのログを有効にするには、CloudTrail でデータプレーン API アクティビティのログを有効にする必要があります。詳細については、「[トレイルのデータイベントのログ記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)」を参照してください。 DynamoDB でアクティビティが発生すると、そのアクティビティはイベント履歴の他の AWS のサービスのイベントと共に CloudTrail イベントにレコードされます。詳細については、「[AWS CloudTrail を使用した DynamoDB オペレーションのログ記録](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/logging-using-cloudtrail.html)」を参照してください。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、*AWS CloudTrailユーザーガイド*の「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。 DynamoDB のイベントなど、AWS アカウントのイベントの継続的なレコードについては、[追跡](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)を作成します。証跡により、CloudTrail はログファイルを Amazon Simple Storage Service (Amazon S3) バケットに配信できます。デフォルトでは、コンソールで証跡を作成すると、証跡がすべての AWS リージョンに適用されます。証跡では、AWS パーティションのすべてのリージョンからのイベントがログに記録され、指定した S3 バケットにログファイルが配信されます。さらに、その他の AWS サービスを設定して、CloudTrail ログで収集したデータをより詳細に分析し、それに基づく対応を行うことができます。 **DynamoDB Streams を使用してデータプレーンオペレーションをモニタリングする** DynamoDB は AWS Lambda と統合されているため、トリガー (DynamoDB Streams 内のイベントに自動的に応答するコードの一部) を作成できます。トリガーを使用すると、DynamoDB テーブル内のデータ変更に対応するアプリケーションを構築できます。 テーブルで DynamoDB Streams を有効にした場合、書き込む Lambda 関数にストリームの Amazon リソースネーム (ARN) を関連付けることができます。テーブルの項目が変更されるとすぐに、新しいレコードがテーブルのストリーミングに表示されます。AWS Lambda はストリーミングをポーリングし、新しいストリーミングレコードを検出すると、 Lambda 関数を同期的に呼び出します。Lambda 関数は、通知の送信やワークフローの開始など、指定したアクションを実行できます。 例については、「[チュートリアル: Amazon DynamoDB Streams で AWS Lambda を使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-ddb-example.html)」を参照してください。この例では、DynamoDB イベント入力を受け取り、それに含まれるメッセージを処理して、受信イベントデータの一部を Amazon CloudWatch Logs に書き込みます。 ** を使用した での DynamoDB 設定のモニタリングAWS Config** [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) を使用すると、AWS リソースの設定変更を継続的にモニタリングおよびレコードできます。また、AWS Config を使用して AWS リソースのインベントリも作成できます。以前の状態からの変更が検出されると、Amazon Simple Notification Service (Amazon SNS) 通知が配信されるので、内容を確認してアクションを実行できます。「[コンソールを使用して AWS Config を設定する](https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html)」のガイダンスに従い、DynamoDB リソースタイプが含まれていることを確認します。 設定変更と通知を Amazon SNS トピックにストリーミングするように AWS Config を設定できます。例えば、リソースの更新時に E メールアドレスに通知が送信されれば、変更を確認できます。AWS Config でカスタムルールまたはマネージドルールを適用してリソースを評価したときにも通知を受け取ることができます。 例については、*AWS Config デベロッパーガイド*の「[AWS Config が Amazon SNS トピックに送信する通知](https://docs.aws.amazon.com/config/latest/developerguide/notifications-for-AWS-Config.html)」を参照してください。 **AWS Config ルール を使用した での DynamoDB コンプライアンスのモニタリング** AWS Config は、リソースで発生する設定変更を継続的に追跡し、これらの変更がルールの条件に違反していないかどうかをチェックします。リソースがルールに違反している場合、AWS Config はリソースとルールに非準拠を示す [noncompliant] のフラグを付けます。 AWS Config を使用してリソースの設定を評価することで、自社プラクティス、業界ガイドライン、および規制に対するリソース設定の準拠状態を確認できます。AWS Config は、[AWS マネージドルール](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)を提供しますが、これは事前定義されているカスタマイズ可能なルールで、AWS Config はこのルールを使用して AWS リソースが一般的なベストプラクティスに準拠しているか評価します。 **識別とオートメーションのために DynamoDB リソースにタグを付ける** AWS のリソースにメタデータをタグ付け形式で割り当てることができます。各タグは、カスタマー定義のキーと値 (オプション) で構成されるシンプルなラベルです。タグを使用すると、リソースの管理、検索、フィルターが容易になります。 タグ付けを行うと、グループ化されたコントロールを実装できます。タグには固有のタイプはありませんが、 用途、所有者、環境などの基準でリソースを分類できます。次に例をいくつか示します。 + セキュリティ — 暗号化などの要件を決定するために使用されます。 + 機密性 — リソースがサポートするデータ機密性レベルの識別子。 + 環境 — 開発、テスト、本番稼働用インフラストラクチャを区別するために使用されます。 詳細については、「[AWS タグ付け戦略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)」および「[DynamoDB のタグ付け](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.html)」を参照してください。 **AWS Security Hub CSPM を使用して、セキュリティのベストプラクティスに関連する Amazon DynamoDB の使用状況をモニタリングします。** Security Hub CSPM は、セキュリティコントロールを使用してリソース設定とセキュリティ標準を評価し、お客様がさまざまなコンプライアンスフレームワークに準拠できるようサポートします。 Security Hub CSPM を使用して DynamoDB リソースを評価する方法の詳細については、「*AWS Security Hub CSPM ユーザーガイド*」の「[Amazon DynamoDB コントロール](https://docs.aws.amazon.com/securityhub/latest/userguide/dynamodb-controls.html)」を参照してください。