DynamoDB グローバルテーブルのセキュリティ
グローバルテーブルレプリカは DynamoDB テーブルであるため、AWS Identity and Access Management (IAM) ID ポリシーやリソースベースのポリシーなど、単一リージョンテーブルに対して行うレプリカへのアクセスを制御するのと同じ方法を使用します。このトピックでは、IAM アクセス許可と AWS Key Management Service (AWS KMS) 暗号化を使用して DynamoDB マルチアカウントグローバルテーブルを保護する方法について説明します。クロスリージョンクロスアカウントレプリケーションと自動スケーリングを許可するリソースベースのポリシーとサービスリンクロール (SLR) について、また、マルチリージョンの結果整合性 (MREC) テーブルに対して、グローバルテーブルの作成、更新、削除に必要な IAM アクセス許可について説明します。また、クロスリージョンレプリケーションを安全に管理するための AWS KMS 暗号化キーについても説明します。
クロスアカウントおよびクロスリージョンテーブルレプリケーションを確立するために必要なリソースベースのポリシーとアクセス許可に関する詳細情報を提供します。このセキュリティモデルを理解することは、安全なクロスアカウントデータレプリケーションソリューションを実装する必要があるお客様にとって不可欠です。
レプリケーションのサービスプリンシパル承認
DynamoDB のマルチアカウントグローバルテーブルは、レプリケーションがアカウントの境界を越えて実行されるため、個別の承認アプローチを使用します。これは、DynamoDB のレプリケーションサービスプリンシパルを使用して行われます (replication.dynamodb.amazonaws.com)。各参加アカウントは、レプリカテーブルのリソースポリシーでそのプリンシパルを明示的に許可し、aws:SourceAccount、aws:SourceArn などのキーのソースコンテキスト条件によって特定のレプリカに制限できるアクセス許可を付与する必要があります。詳細については、「AWS グローバル条件キー」を参照してください。アクセス許可は双方向です。つまり、レプリケーションを特定のレプリカのペア間で確立する前に、すべてのレプリカが相互にアクセス許可を明示的に付与する必要があります。
クロスアカウントレプリケーションには、次のサービスプリンシパルのアクセス許可が不可欠です。
-
dynamodb:ReadDataForReplicationは、レプリケーション目的でデータを読み取る機能を付与します。このアクセス許可により、1 つのレプリカの変更を読み取って他のレプリカに伝播できます。 -
dynamodb:WriteDataForReplicationは、レプリケート先テーブルへのレプリケートデータの書き込みを許可します。このアクセス許可により、グローバルテーブル内のすべてのレプリカ間で変更を同期できます。 -
dynamodb:ReplicateSettingsを使用すると、レプリカ間でテーブル設定を同期できるため、すべての参加テーブルで一貫した設定が可能になります。
各レプリカは、上記のアクセス許可を他のすべてのレプリカとそれ自体に付与する必要があります。つまり、ソースコンテキスト条件には、グローバルテーブルを構成するレプリカの完全なセットが含まれている必要があります。これらのアクセス許可は、新しいレプリカがマルチアカウントグローバルテーブルに追加されるたびに検証されます。これにより、レプリケーションオペレーションが承認された DynamoDB サービスによってのみ実行され、目的のテーブル間でのみ実行されることが検証されます。
マルチアカウントグローバルテーブルのサービスリンクロール
DynamoDB マルチアカウントグローバルテーブルは、すべてのレプリカ間で設定をレプリケートするため、各レプリカは一貫したスループットで同じようにセットアップされ、シームレスなフェイルオーバーエクスペリエンスを提供します。設定のレプリケーションは、サービスプリンシパルに対する ReplicateSettings アクセス許可によって制御されますが、特定のクロスアカウントクロスリージョンレプリケーションと自動スケーリング機能の管理には、サービスにリンクされたロール (SLR) も利用します。これらのロールは、AWS アカウントごとに 1 回だけ設定されます。作成後、同じロールがアカウント内のすべてのグローバルテーブルに機能します。サービスリンクロールの詳細については、IAM ユーザーガイドの「サービスリンクロールの使用」を参照してください。
設定管理サービスにリンクされたロール
Amazon DynamoDB は、アカウントで最初のマルチアカウントグローバルテーブルレプリカを作成すると、AWSServiceRoleForDynamoDBGlobalTableSettingsManagement サービスリンクロール (SLR) を自動的に作成します。このロールは、クロスアカウントクロスリージョンの設定のレプリケーションを管理します。
リソースベースのポリシーをレプリカに適用する場合は、AWSServiceRoleForDynamoDBGlobalTableSettingsManagement で定義されている SLR プリンシパルのアクセス許可をいずれも拒否しないことを確認してください。拒否すると、設定管理が妨げられ、レプリカ間または GSI 間でスループットが一致しない場合にレプリケーションに支障をきたす可能性があります。必要な SLR アクセス許可を拒否すると、影響を受けるレプリカとの間のレプリケーションが停止し、レプリカテーブルのステータスは「REPLICATION_NOT_AUTHORIZED」に変わります。マルチアカウントグローバルテーブルについて、レプリカが 20 時間以上「REPLICATION_NOT_AUTHORIZED」ステータスのままである場合、レプリカは 1 つのリージョンの DynamoDB テーブルに変換され、元に戻せなくなります。SLR には、以下のアクセス許可があります。
-
application-autoscaling:DeleteScalingPolicy -
application-autoscaling:DescribeScalableTargets -
application-autoscaling:DescribeScalingPolicies -
application-autoscaling:DeregisterScalableTarget -
application-autoscaling:PutScalingPolicy -
application-autoscaling:RegisterScalableTarget
自動スケーリングサービスにリンクされたロール
プロビジョンドキャパシティモードのグローバルテーブルを設定する場合は、グローバルテーブルに自動スケーリングを設定する必要があります。DynamoDB 自動スケーリングは、AWS Application Auto Scaling Service を使用して、グローバルテーブルレプリカのプロビジョニングされたスループットキャパシティを動的に調整します。Application Auto Scaling サービスは、AWSServiceRoleForApplicationAutoScaling_DynamoDBTable という名前のサービスにリンクされたロール (SLR) を作成します。このサービスにリンクされたロールは、DynamoDB テーブルの自動スケーリングを初めて設定するときに、AWS アカウントで自動的に作成されます。これにより、Application Auto Scaling はプロビジョニングされたテーブル容量を管理でき、CloudWatch アラームを作成できます。
リソースベースのポリシーをレプリカに適用する際は、AWSApplicationAutoscalingDynamoDBTablePolicy で定義されている Application Auto Scaling SLR プリンシパルへのアクセス許可を拒否していないことを確認してください。拒否すると、自動スケーリング機能が中断されます。
グローバルテーブルで AWS IAM を使用する方法
次のセクションでは、さまざまなグローバルテーブルのオペレーションに必要なアクセス許可について説明し、ユーザーとアプリケーションに適切なアクセスを設定するのに役立つポリシーの例を示します。
注記
説明されているすべてのアクセス許可は、影響を受けるリージョンの特定のテーブルリソース ARN に適用する必要があります。テーブルリソース ARN は arn:aws:dynamodb:region:account-id:table/table-name の形式に従います。ここでは、実際のリージョン、アカウント ID、テーブル名の値を指定する必要があります。
以下のセクションでは、順を追って以下のトピックを取り上げます。
-
マルチアカウントグローバルテーブルの作成とレプリカの追加
-
マルチアカウントグローバルテーブルの更新
-
グローバルテーブルとレプリカの削除
グローバルテーブルの作成とレプリカの追加
グローバルテーブルを作成するためのアクセス許可
リージョンテーブルに新しいレプリカを追加してマルチアカウントグローバルテーブルを作成する場合、または既存のマルチアカウントグローバルテーブルに追加する場合、アクションを実行する IAM プリンシパルは既存のすべてのメンバーによって承認される必要があります。既存のメンバーはすべて、レプリカを正常に追加するために、テーブルポリシーで次のアクセス許可を付与する必要があります。
-
dynamodb:AssociateTableReplica- このアクセス許可により、テーブルをグローバルテーブル設定に結合できます。これは、レプリケーション関係の初期確立を可能にする基本的なアクセス許可です。
この正確なコントロールにより、承認されたアカウントのみがグローバルテーブルのセットアップに参加できるようになります。
グローバルテーブルの作成のための IAM ポリシーの例
マルチアカウントグローバルテーブルのセットアップは、安全なレプリケーションを提供する特定の認可フローに従います。顧客が 2 つのレプリカを持つグローバルテーブルを確立するという実践的なシナリオを順に見ていくことで、これが実際にどのように機能するかを確認してみましょう。最初のレプリカ (ReplicaA) は ap-east-1 リージョンのアカウント A に存在し、2 番目のレプリカ (ReplicaB) は eu-south-1 リージョンのアカウント B にあります。
-
ソースアカウント (アカウント A) では、プロセスはプライマリレプリカテーブルの作成から始まります。アカウント管理者は、関連付けを実行するために必要なアクセス許可を送信先アカウント (アカウント B) に明示的に付与するリソースベースのポリシーをこのテーブルにアタッチする必要があります。このポリシーは、DynamoDB レプリケーションサービスが重要なレプリケーションアクションを実行することも許可します。
-
送信先アカウント (アカウント B) は、レプリカの作成時に対応するリソースベースのポリシーをアタッチし、レプリカの作成に使用するソーステーブル ARN を参照することで、同様のプロセスに従います。このポリシーは、アカウント A によって付与されたアクセス許可をミラーリングし、信頼された双方向の関係を作成します。レプリケーションを確立する前に、DynamoDB はこれらのクロスアカウントアクセス許可を検証して、適切な承認が設定されていることを確認します。
このセットアップを確立するには。
-
アカウント A の管理者は、まずリソースベースのポリシーを ReplicaA にアタッチする必要があります。このポリシーは、アカウント B と DynamoDB レプリケーションサービスに必要なアクセス許可を明示的に付与します。
-
同様に、アカウント B の管理者は、一致するポリシーを ReplicaB にアタッチする必要があります。アカウント参照を逆にして、レプリカ A をソーステーブルとして参照するレプリカ B を作成するためのテーブル作成呼び出しで、対応するアクセス許可をアカウント A に付与します。
この設定では、アカウント A、アカウント B、アカウント C に、それぞれ 3 つのレプリカ ReplicaA、ReplicaB、および ReplicaC があります。ReplicaA は最初のレプリカであり、リージョンテーブルとして開始され、その後に ReplicaB と ReplicaC が追加されます。
-
アカウント A の管理者は、まず、すべてのメンバーとのレプリケーションを許可し、アカウント B とアカウント C の IAM プリンシパルがレプリカを追加できるように、リソースベースのポリシーを ReplicaA にアタッチする必要があります。
-
アカウント B の管理者は、ReplicaA をソースとしてポイントするレプリカ (ReplicaB) を追加する必要があります。ReplicaB には、すべてのメンバー間のレプリケーションを許可し、アカウント C にレプリカの追加を許可する次のポリシーがあります。
-
最後に、アカウント C の管理者は、すべてのメンバー間のレプリケーションアクセス許可を許可する次のポリシーを使用してレプリカを作成します。ポリシーにより、これ以上のレプリカの追加は許可されません。
マルチアカウントグローバルテーブルの更新
UpdateTable API を使用して既存のグローバルテーブルのレプリカ設定を変更するには、API コールを行うリージョンのテーブルリソースに対して次のアクセス許可が必要です。dynamodb:UpdateTable
自動スケーリングポリシーや有効期限設定など、他のグローバルテーブル設定も更新できます。これらの追加の更新オペレーションには、次のアクセス許可が必要です。
UpdateTimeToLive API を使用して有効期限設定を更新するには、レプリカを含むすべてのリージョンのテーブルリソースに対して次のアクセス許可が必要です。dynamodb:UpdateTimeToLive
UpdateTableReplicaAutoScaling API を使用してレプリカの自動スケーリングポリシーを更新するには、レプリカを含むすべてのリージョンのテーブルリソースに対して、次のアクセス許可が必要です。
-
application-autoscaling:DeleteScalingPolicy -
application-autoscaling:DeleteScheduledAction -
application-autoscaling:DeregisterScalableTarget -
application-autoscaling:DescribeScalableTargets -
application-autoscaling:DescribeScalingActivities -
application-autoscaling:DescribeScalingPolicies -
application-autoscaling:DescribeScheduledActions -
application-autoscaling:PutScalingPolicy -
application-autoscaling:PutScheduledAction -
application-autoscaling:RegisterScalableTarget
注記
テーブルの更新を成功させるには、すべてのレプリカリージョンとアカウントで dynamodb:ReplicateSettings アクセス許可を付与する必要があります。いずれかのレプリカがマルチアカウントグローバルテーブル内のいずれかのレプリカに設定をレプリケートするアクセス許可を付与していない場合、アクセス許可が修正されるまで、すべてのレプリカのすべての更新オペレーションは AccessDeniedException で失敗します。
グローバルテーブルとレプリカの削除
グローバルテーブルを削除するには、すべてのレプリカを削除する必要があります。同一アカウントグローバルテーブルとは異なり、UpdateTable を使用してリモートリージョン内のレプリカテーブルを削除することはできません。各レプリカはそのテーブルを制御するアカウントから DeleteTable API を介して削除する必要があります。
グローバルテーブルとレプリカを削除するアクセス許可
個々のレプリカを削除したり、グローバルテーブルを完全に削除したりするには、次のアクセス許可が必要です。グローバルテーブル設定を削除すると、異なるリージョンのテーブル間のレプリケーション関係のみが削除されます。最後に残っているリージョンの基盤となる DynamoDB テーブルは削除されません。最後のリージョンのテーブルは、同じデータと設定を持つ標準の DynamoDB テーブルとして引き続き存在し続けます。
レプリカを削除する各リージョンのテーブルリソースには、次のアクセス許可が必要です。
-
dynamodb:DeleteTable -
dynamodb:DeleteTableReplica
グローバルテーブルで AWS KMS を使用する方法
すべての DynamoDB テーブルと同様に、グローバルテーブルレプリカは常に AWS Key Management Service (AWS KMS) に保存されている暗号化キーを使用して保管中のデータを暗号化します。
注記
同一アカウントグローバルテーブルとは異なり、マルチアカウントグローバルテーブル内の異なるレプリカは、異なるタイプの AWS KMS キー (AWS 所有キー、またはカスタマーマネージドキー) を使用して設定できます。マルチアカウントグローバルテーブルは AWS マネージドキーをサポートしていません。
CMK を使用するマルチアカウントグローバルテーブルでは、各レプリカのキーポリシーで、レプリケーションと設定管理のためのキーにアクセスするためのアクセス許可を DynamoDB レプリケーションサービスプリンシパル (replication.dynamodb.amazonaws.com) に付与する必要があります。以下のアクセス権限が必要です。
-
kms:Decrypt -
kms:ReEncrypt* -
kms:GenerateDataKey* -
kms:DescribeKey
重要
DynamoDB では、レプリカを削除するには、レプリカの暗号化キーにアクセスする必要があります。レプリカを削除するため、レプリカの暗号化に使用されるカスタマーマネージドキーを無効化または削除する場合、まずレプリカを削除し、残りのレプリカの 1 つで記述を呼び出してレプリケーショングループからテーブルが削除されるまで待機してから、キーを無効化または削除する必要があります。
レプリカの暗号化に使用されるカスタマーマネージドキーへの DynamoDB のアクセスを無効化または取り消すと、レプリカとの間のレプリケーションは停止し、レプリカのステータスは「INACCESSIBLE_ENCRYPTION_CREDENTIALS」に変わります。レプリカが 20 時間以上「INACCESSIBLE_ENCRYPTION_CREDENTIALS」ステータスのままである場合、レプリカは単一リージョンの DynamoDB テーブルに変換され、元に戻せなくなります。
AWS KMS ポリシーの例
この AWS KMS ポリシーにより、DynamoDB はレプリカ A と B 間のレプリケーションのために両方の AWS KMS キーにアクセスできます。各アカウントの DynamoDB レプリカにアタッチされた AWS KMS キーは、次のポリシーで更新する必要があります。