Amazon DynamoDBのアクセス制御とネットワーク保護

Amazon DynamoDBを安全に使うには、誰がどのAPIを呼び出せるか、どのデータに触れられるか、アプリケーションからAWSサービスまでをどの経路で接続するかを分けて考えます。IAMはAPI操作とリソースへのアクセスを制御し、VPC endpointはVPCからDynamoDBへ向かうネットワーク経路を制御します。どちらか一方だけで保護が完了するわけではありません。

保存データはDynamoDBによって暗号化され、API通信にはTLSを使います。さらにKMSキーの管理、アイテムや属性の保護、アプリケーションの認証設計が必要な場合は、暗号化や認可の要件を追加します。ここでは特に、DynamoDB固有のリソース指定とVPC endpointの違いを整理します。

API操作をIAMで制御する

アプリケーションはHTTPS経由でDynamoDB APIを呼び出します。IAMポリシーでは、許可する操作を dynamodb:GetItem、dynamodb:PutItem、dynamodb:UpdateItem、dynamodb:DeleteItem、dynamodb:Query、dynamodb:Scan などのアクションで指定します。読み取りだけを行う処理に書き込みアクションを含める必要はありません。必要なAPIだけを許可すると、認証情報が誤用されたときの影響を抑えられます。

権限の対象はDynamoDBのリソースARNで絞り込みます。テーブル、セカンダリインデックス、DynamoDB Streamsはそれぞれ異なるARNを持ちます。たとえば、インデックスを使う Query を許可するときは、そのインデックスARNも対象に含める必要があります。Streamsのレコードを読むAPIはストリームARNを対象にし、テーブルのアイテムを読む権限とは別に設定します。

リソース	ARNの形	主な対象
テーブル	arn:aws:dynamodb:リージョン:アカウントID:table/テーブル名	テーブルのアイテム操作やテーブル情報の取得
インデックス	arn:aws:dynamodb:リージョン:アカウントID:table/テーブル名/index/インデックス名	インデックスを対象とする Query など
ストリーム	arn:aws:dynamodb:リージョン:アカウントID:table/テーブル名/stream/ストリームラベル	Streamsの説明、シャード取得、レコード読み取り

リソースベースポリシーをサポートするテーブルやストリームには、リソース側に許可を記述できます。別アカウントのアプリケーションへアクセスを認める場合は、所有側リソースのポリシーだけでなく、呼び出し元のIAMポリシー、Organizationsの制御ポリシー、必要に応じて暗号化キーのポリシーも確認します。明示的な拒否は許可より優先されます。

条件キーでアイテムや属性を絞る

テーブルに対する GetItem や Query を許可するだけでは、呼び出し元がテーブル内のどのアイテムを読めるかまでは制限されません。IAMの条件キーを加えると、テーブルを共有しながらアクセス範囲を絞れます。

dynamodb:LeadingKeys はリクエストが指定するパーティションキー値を条件にします。たとえば、設備点検アプリで TEAM#north のようなチーム識別子をパーティションキーに含めれば、担当チームのキーだけを許可するポリシーを作れます。この方法を使うには、テナントやチームの境界がキー設計に反映されている必要があります。条件キーはソートキー単独での範囲制限を意味しないため、パーティションキーの構造と実際のアクセスAPIを合わせて設計します。

dynamodb:Attributes などの条件キーは、リクエストが扱える属性を絞る用途に使えます。パーティションキーによるアイテム範囲の制限と、属性の読み書き制限は別の制御です。たとえば、利用者ごとの情報を同じテーブルに保存し、各利用者には自分のチームの項目だけを見せ、内部運用属性は変更させない設計では、キー条件と属性条件、許可アクションを組み合わせて検討します。Scan のように個々のパーティションキーを指定しない操作を許可していないかも確認します。

IAMポリシーはロールや利用者ごとに分け、アプリケーションへ渡す認証情報には必要な範囲だけを持たせます。テーブル全体へのワイルドカード許可や、読み取り専用処理への書き込み許可を避け、インデックスとStreamsのアクセスも実際の処理に応じて追加します。

VPCからDynamoDBへプライベート接続する

DynamoDBのAPIはAWSのサービスエンドポイントに送られます。プライベートサブネットからの経路を明確にするには、VPC endpointを利用できます。DynamoDBではGateway endpointとInterface endpointの両方を選択でき、接続元の場所や運用要件によって向き不向きが異なります。

Gateway VPC endpoint

Gateway endpointはDynamoDB向けのサービスプレフィックスリストへのルートを、選択したVPCルートテーブルに追加する方式です。VPC内のサブネットからDynamoDBへ向かう通信は、そのルートを通ってAWSネットワーク内を進みます。NAT GatewayやInternet Gatewayを経由せずに接続でき、Gateway endpoint自体に時間単位やデータ処理単位の料金はありません。

endpointを作成するときに、利用するルートテーブルを関連付けます。ルートテーブルを共有すれば、複数のサブネットから同じendpointを利用できます。endpointを作成しただけではすべてのVPC内通信が自動的に対象になるわけではなく、適切なルートテーブルとの関連付けが必要です。

Gateway endpointにはendpoint policyを設定できます。既定のポリシーはendpoint経由でのアクセスを広く許可するため、対象のテーブルやアクションを限定すると、誤った経路からのアクセスを防ぐ追加の境界になります。ただしendpoint policyだけで利用者へDynamoDBの権限を付与することはできません。IAM identity policyやリソースベースポリシーによる許可も必要です。

Interface VPC endpoint

Interface endpointはAWS PrivateLinkを使い、選択したサブネットにネットワークインターフェイス（ENI）を作成します。セキュリティグループで通信を制御でき、オンプレミス環境や別VPCなど、Gateway endpointでは直接利用できない接続元からDynamoDBへプライベート接続したい場合に適します。DNS設定やVPCのDNS解決も接続設計に含めます。

Interface endpointにはendpoint ENIごとの時間料金と処理データ量に応じた料金がかかります。また、endpoint ENIに適用するセキュリティグループでHTTPS通信を許可する必要があります。VPC内部のワークロードからDynamoDBへ接続するだけであれば、追加料金がなくルートテーブルで制御するGateway endpointが一般にシンプルです。PrivateLinkの到達性やセキュリティグループによる制御が必要な場合はInterface endpointを検討します。

比較点	Gateway endpoint	Interface endpoint
接続方式	ルートテーブルにサービス宛てのルートを追加	サブネットに作成したendpoint ENIを経由
ネットワーク制御	関連付けたルートテーブルとendpoint policy	セキュリティグループ、DNS、endpoint policy
主な接続元	endpointと同じVPC内のサブネット	VPC内に加え、PrivateLinkで接続する他VPCやオンプレミス環境
endpointの料金	endpoint自体の時間料金・データ処理料金なし	endpoint時間料金とデータ処理料金あり
選択の目安	VPC内の一般的なDynamoDBアクセス	PrivateLinkの接続性やENI単位の制御が必要

Gateway型endpointを提供するAWSサービスはAmazon S3とDynamoDBです。これは「その2サービスにしかVPC endpointがない」という意味ではありません。他の多くのAWSサービスやDynamoDBのPrivateLink接続にはInterface endpointを使います。endpointの種類と対象サービスを区別して選びます。

IAM・endpoint policy・暗号化を重ねる

リクエストがDynamoDBへ届くネットワーク経路と、そのAPI操作を実行する権限は別々の判定です。endpoint policyは特定のendpointを通過するリクエストを絞り、IAM identity policyとリソースベースポリシーは呼び出し元とリソースの間で許可する操作を決めます。endpoint policyに許可があってもIAM権限がなければAPI操作は成功せず、IAMで許可されていてもendpoint policyが拒否すればそのendpoint経由では通過できません。

通信中のAPI要求はTLSで保護され、DynamoDBの保存データは保存時暗号化の対象です。保存時暗号化で使うKMSキーの選択や管理には、キーの権限、ローテーション、監査要件も関わります。サービス側の保存時暗号化は、アプリケーションが属性を暗号化してから保存するクライアント側暗号化とは異なります。AWSやテーブル操作権限を持つ主体にも特定の属性の平文を見せない要件では、アプリケーション側の暗号化を別途検討します。

要件から構成を選ぶ

要件	検討する設定
バックエンドが必要なテーブルだけを読み書きする	IAMのアクションとテーブルARNを限定する
インデックス検索だけを追加で許可する	対象のインデックスARNと Query など必要なアクションを設定する
Streamsの変更イベントを処理する	テーブル操作権限と区別して、ストリームARNおよびストリーム読み取りアクションを許可する
利用者ごとにアイテム範囲を分ける	パーティションキーの設計に dynamodb:LeadingKeys を合わせる
プライベートサブネットからDynamoDBへ接続する	ルートテーブルとendpoint policyを使うGateway endpointを検討する
オンプレミスや他VPCからプライベート接続する	PrivateLink、DNS、ENI、セキュリティグループと料金を含めてInterface endpointを検討する
AWS側でも平文を扱わせない属性がある	サービスの保存時暗号化に加えてクライアント側暗号化を評価する

試験で押さえるポイント

• DynamoDBへのアクセスはAPI単位でIAM制御し、テーブル、インデックス、StreamsのARNと許可アクションを対応させる。
• dynamodb:LeadingKeys を使うとパーティションキー値に基づくアイテム範囲の制限を設計できる。属性制限やAPI制限は別の条件として扱う。
• Gateway endpointはルートテーブルにDynamoDB向け経路を追加する。VPC内の接続でNAT Gatewayを避けられ、endpoint自体の料金はない。
• Gateway endpointを提供するのはS3とDynamoDBだが、DynamoDBにはInterface endpointもある。PrivateLink接続ではInterface endpointを検討する。
• endpoint policyはアクセス制御の追加境界であり、IAMやリソースベースポリシーの許可に置き換わらない。
• DynamoDBは転送中のTLSと保存時暗号化を提供する。アプリケーションレベルや属性単位の暗号化要件は個別に設計する。

AWS公式ドキュメント

• DynamoDBのIAMによるアクセス制御
• DynamoDBのリソースベースポリシー
• DynamoDBのVPC endpoint
• DynamoDBのPrivateLink（Interface endpoint）
• Amazon DynamoDBの暗号化
• Amazon DynamoDBのサービス認可リファレンス

関連トピック

• DynamoDBのキー設計とセカンダリインデックス
• DynamoDBの項目操作・Query・Scan・トランザクション
• DynamoDB Streamsによる変更データの処理
• VPCエンドポイントとAWS PrivateLink
• AWS IAMポリシー：JSON構造・種類・評価とサービス連携